Команда разработчиков OpenVZ объявила (http://ru-openvz.livejournal.com/5753.html) о выходе первой версии утилиты CRtools (http://git.criu.org/?p=crtools.git;a=summary), предназначенной для обеспечения работы в Linux функции по созданию контрольных точек для работающих приложений и последующего восстановления работы с сохранённой позиции. Например, можно заморозить состояние одного или группы процессов, а затем возобновить работу с сохранённой позиции на другой машине или после перезагрузки текущей системы. Из областей применения также отмечается Live-миграция изолированных контейнеров, ускорение старта медленных процессов, проведение обновлений ядра без парезапуска сервисов, периодическое сохранение состояния долговыполняемых вычислительных задач для возобновления работы в случае краха системы, миграция активных десктоп-сеансов с одной машины на другую.Реализованная система заморозки процессов примечательна тем, что основной код для обеспечения работы данной функциональности реализован не на уровне ядра Linux, а в пространстве пользователя. Работа контрольных точек создаётся непосредственно представленной утилитой, при задействовании минимального числа специфичных функций, работающих на уровне ядра. Разработка выполнена в рамках проекта CRIU (http://criu.org) (Checkpoint/Restore In Userspace), за год существования которого добавлена возможность обрабатывать почти все приложения, и в ядре 3.5 уже есть 90% необходимой для этого возможностей.
В настоящее время в CRtools реализована поддержка заморозки групп процессов и сессий, состояния маппинга памяти, нитей, открытых файлов, именованных и неименованных каналов, сокетов (в том числе TCP, что позволяет обеспечить миграцию процесса без разрыва сетевого соединения), IPC и т.п. Из архитектур пока поддерживается только x86_64. В ближайшее время ожидается поддержка контейнеров (в том числе и LXC).
URL: http://ru-openvz.livejournal.com/5753.html
Новость: http://www.opennet.me/opennews/art.shtml?num=34408
Круто, теперь можно будет сделать activities из кде на openbox без костылей
А чё будет если заморозить процесс, во время заморозки процесса?! =)
/0
> А чё будет если заморозить процесс, во время заморозки процесса?! =)я думаю блокировку не отменили...)))
>> А чё будет если заморозить процесс, во время заморозки процесса?! =)
> я думаю блокировку не отменили...)))А чё будет если заморозится блокировка, заморозки процесса, во время заморозки процесса?!
При разморозки получим скайнет и улетим сингулярность?
CONFIG_CGROUP_FREEZER: Provides a way to freeze and unfreeze all tasks in a cgroup.
Symbol: CGROUP_FREEZER [=y]так что сабж — попытка реализовать юзерспейсные утилиты в удобном виде.
и не более.
> так что сабж — попытка реализовать юзерспейсные утилиты в удобном виде. и не более.Я никогда не занимался этой фигнёй. Уж слишком большая вероятность сбоя после разморозки.
Если для приложений типа atd, cron это прокатит, то для многоуровневой софтины с большим
кол-вом зависимостей, особо аппаратных, вероятность стремится к 1. Можете потренироваться
заморозив Oil Rush, VMware или Wine.
а чем это принципиально от пошагового дебагинга отличается?
> а чем это принципиально от пошагового дебагинга отличается?Тем, что дебажить надо всё, и дрова видюхи, и регисты видюхи,
сетевуху, ядро, со всеми флагами и состояниями...
Я о том, что замороженный софт восстановит свое состояние, а
как это понравится ядру, видюхи, и сетывым соединениям?!
В лучшем случае переинициализация, что по сути равносильно обычному запуску,
в худшем - сегфолты с oops_ами и опять переинициализация.
>Тем, что дебажить надо всё, и дрова видюхи, и регисты видюхи, сетевуху, ядро, со всеми флагами и состояниями...глупости, если речь идёт о юзерспейсных задачах (а о них и говорим).
тут достаточен контекст выполнения его и потомков, включая потоки, и его же (и потомков, ежели это процессы) адресное пространство.
>В лучшем случае переинициализация, что по сути равносильно обычному запуску,в худшем - сегфолты с oops_ами и опять переинициализация.
если речь идёт о контейнерах, то и тут в ядре нужные механизмы уже есть. и ещё сабж добавит.зыж
я понимаю твою озабоченность, как любителя блоба нвидиа. сочувствую.
но она сама на стандарты разработки в линухе (да и юниксах) болт положила. все её дрова — это тотже код, что и в винде на 99%.
но и тут, если в суспенд/гибернейт уходит, то и в сабже будет работать.
хотя нах в контейнерах нвидиа мне не понятно. а всякие куды/шмуды пущай через сервер пускают, один хер очередь выполнения.
> дебагингау вас из жопы торчит
> заморозив Oil Rush, VMware или Wine.Как минимум вмварь сама умеет морозить виртуалки ;)
Вы не совсем поняли, что это они уже пропихнули эту фичу в ядро.
А что будет если ты сам себе в ногу выстрелишь?
Заморозится процесс заморозки процесса :)
reboot?
Круто, теперь можно интегрировать это в systemd и перезагружаться с новым ядром без перезапуска сервисов.
А что... перезагрузка ос без перезагрузки программ? В этом что-то есть :)
Надо микроядерным делать всё, пускай всё перегружается когда приспичит.
Сдохла сетевуха - процесс заморозил, вынул, новую вставил, разморозил, работаем дальше....Где-то это уже было... :-/
---
Разные ядра, для разных приложений ещё не придумали, не?!
> Надо микроядерным делать всё, пускай всё перегружается когда приспичит.Так делай :).
> Сдохла сетевуха - процесс заморозил, вынул, новую вставил, разморозил, работаем дальше....
А что мешает фризануть процесс на пингвине, заменить сетевку, выставить ей параметры "как было" (mac, IP, ...) и расфризить процесс? Пингвигн вроде даже hotplug в pci-e умеет нынче, так что подключение на горячую ничему особо и не противоречит :). Думаю что это и на модульном монолите вполне реалистично обыграть. Как будто программам есть большая разница кто разрулит их сисколы и как он там внутрях изогнется для этого.
> А что... перезагрузка ос без перезагрузки программ? В этом что-то есть :)И даже без разрыва сетевых соединений.
А еще можно перезагружать ядро через kexec, минуя биос (systemd умеет). Так как процессы не придется запускать заново, то времени должно уйти очень мало. Клиенты даже ничего не заметят.
а кто сказал, что процессы после перезапуска ядра продолжают работать?
Кто-нибудь использовал? Как оно?
Осталось запилить его в шедулер и наслаждаться баттхёртом Завалишина
> Осталось запилить его в шедулер и наслаждаться баттхёртом ЗавалишинаУ Завалишина это не главное.
>> Осталось запилить его в шедулер и наслаждаться баттхёртом Завалишина
> У Завалишина это не главное.Ну да, очередной кульный концепт. Ну у Таненбаума хоть отмазка есть - для обучения как [не надо] писать операционные системы. А у этих что мотиватором служит? Роснанопил?
>>> Осталось запилить его в шедулер и наслаждаться баттхёртом Завалишина
>> У Завалишина это не главное.
> Ну да, очередной кульный концепт. Ну у Таненбаума хоть отмазка есть -
> для обучения как [не надо] писать операционные системы. А у этих
> что мотиватором служит? Роснанопил?у этих - это у Parallels. Они честно говорили, что их задача на ближайшие пару лет - включить контейнерную технологию (OpenVZ, Virtuozzo) в мейнстрим. Вот уже дают стране угля
Про пару лет они говорили еще в 2006м. А воз и ныне там..
У Завалишина как раз, похоже, баттхёрт главное.
> У Завалишина это не главное.А что у него главное, если не секрет?
В DragonFlyBSD эту фичу Метт Диллон еще сто лет назад сделал, и там это "искарабочное" решение
> В DragonFlyBSD эту фичу Метт Диллон еще сто лет назад сделал, и
> там это "искарабочное" решениеА как оно там называется? Интересно почитать.
http://leaf.dragonflybsd.org/cgi/web-man?command=checkpt...
ХА! ржачно!
ну посмотрите вот это что ли http://dmtcp.sourceforge.net/index.html
а историю можете начать с http://en.wikipedia.org/wiki/Application_checkpointing#Pract...
> Most kernel based checkpointing packages developed to date run under either the 2.4 or 2.6 subfamilies of the Linux kernel on i686 architectures.сабж покруче будет. читайте внимательнее 3-ий абзец.
зыж
но ведь главное громко крикнуть надо! «В DragonFlyBSD… Метт Диллон… сто лет… "искарабочное" решение» :D
ещё бы там виртуалки с контенерами были бы. и "искарабочно" лив-мигрировали бы. и вапче красота.
Нечто подобное было в Linux свыше 10 лет назад...
остановка процесса для дебагинга… это даже не фича.
даже для драгонфлай.сабж же гораздо более объемлющ.
там вон живая миграция на другие железяки указана. без всяких гиперпупервизоров и виртуализации, а на уровне контейнеров.
> там вон живая миграция на другие железяки указана. без всяких гиперпупервизоров и
> виртуализации, а на уровне контейнеров.Дык openvz это умеет уже сколько-то лет.
а сабж и есть openvz.
вернее его будущая часть.
надоело ребятам ядро патчить. :D
> а сабж и есть openvz.
> вернее его будущая часть.
> надоело ребятам ядро патчить. :DНаверное, opvenvz интегрируют в мейнстрим все же раньше, чем допилят мейнстримный LXC.
Интересно, а если так плазму фризнуть после старта и дампануть, потом при старте кед просто вытаскивать из заморозки ;/ Годна штука.
Фраза "С разморозкой" получит новый смысл
> Фраза "С разморозкой" получит новый смыслА что, это будет применимо и к человекам? :)
Скоро можно будет мышкой на флешку компьютер скинуть, а в другом месте вытащить, и как будто ничего не останавливалось. :)
> Скоро можно будет мышкой на флешку компьютер скинуть, а в другом месте
> вытащить, и как будто ничего не останавливалось. :)Уже сто лет как можно - виртуальная машина называется.
что-же -- огромная благодарность данной команде разрабов, до этого был только один более-менее рабочий checkpoint/restart инструмент в виде blcr, но фич у него много меньше.
Вот тоже хотел его упомянуть. Не то чтобы я им уже пользовался, просто openmpi его по зависимости потянул, а оно каждый раз при обновлении ядра на глаза попадается. И каждый раз с ошибкой (debian testing). Помню из описания, что сокеты оно ещё не в состоянии замораживать.
Ребятки жеребятки - снова открыли для себя OS/400.
> Ребятки жеребятки - снова открыли для себя OS/400.Ещё далеко не до конца, не переживайте. Компьютерный прогресс не остановить - пока ещё системы 80-х годов не вполне догнали. :-)
чем это лучше cryopid ?
Почему я это читаю в 2021 году ?!