Вышла новая версия утилиты для «заморозки» и «разморозки» процессов в Linux — CRIU 2.0

А зачем пользователю замораживать и размораживать состояния процессов? Можно огласить примеры применения?

вы про это «Доступен релиз инструментария для сохранения и восстановления состояния процессов в ОС Linux в пространстве пользователя» или это «сохранение состояния процесса пользователем без привилегий» ?

Сохранения в игорях, где это не предусмотрено например (да, читерство)

Ничего себе! Так можно разве? И можно ли такими сейвами обмениваться?

Контейнерная виртуализация -> заморозили набор процессов, перекинули на другой хост -> разморозили

Естественно требует нетривиальной настройки, но, блин, кому сейчас легко?

Увы, на деле оно пока для таких целей непригодно.
Близжайшая альтернатива - гиернация или запись состояния полной виртуальной машины с ядром. вроде vbox умеет.

а почему сейчас не пригодно? есть какие-то технические трудности?

Для игорей наверное нужно сохранять состояние видеокарты, думаю это либо костыльно и геморройно, либо невозможно. Ну и вообще игори сами по себе сложные и проблемные. Да и не про них CRIU писан, он про миграцию контейнеров и прочие серверные ништяки. Хотя разрабы вроде хватались что иксовое приложение тоже получалось мигрировать.

В случае с полной системой (гибернация) это обычно работает, но доя отдельного процессса - беда.
я пытался мигрировать иксовае - получал bad mapping при восстановлении.
а вобще - это скорее всего возможно только при условии, что иксы остались те же и зависшее окно всё ещё на экране, а у приложения тот же адрес (что вроде неврзможно т.к после заморозки процесса он умирает и закрывает своп сокеты)

А каким образом возможна сама заморозка процесса, разделенного на потоки, хранимые и управляемые в ядре системы? Как возможно собрать процесс из потоков и затем обратно его «распараллелить»?

Ну вот так вот, возможна :]

man ptrace.

да. рукопопы и неосиляторы

Чего только люди не придумают, лишь бы не пользоваться полноценными виртуалками.

kill -s SIGSTOP

kill -s SIGCONT

не?

Вы слышали о комнатах в KDE? Это что-то вроде рабочих столов, только процессы на одном рабочем столе «выключаются», а потом включаются по возвращению.

Я как-то пытался такое реализовать в FVWM, используя сигналы SIGSTOP и SIGCONT Делаю в FVWM аналог комнат KDE

Потом, когда процесс зависает, отжирая 100% процессора, а тебе «щя некогда», — посылаю ему SIGSTOP. Firefox любит зависать, обрабатывая JavaScript.

Так то да. Юникс вей. Кисс. Люто. Для акробатов все сигналы тутмна kill -l

А зачем пользователю замораживать и размораживать состояния процессов? Можно огласить примеры применения?

вместо suspend to disk например.

SIGSTOP/SIGTSTP каждый дурак может, а ты попробуй ребутнись/перенеси процесс на железку в соседней стойке перед SIGCONT!

ваще ништяк. Меня давно бесило то, что clementine стартует около 10 секунд.

ФантомОС капец?

Запрещенный прием. Получится токмо с помощью Господней и при совместимости святых духов. Даем сигнал и вознося хвалу создателю хибернейтимся. Изымаем благодатный носитель из неблагодатной стойки и несем в новое святилище, где и запусчаем горение огня. Ву-а-ля! Профит!

круто

kill -s SIGSTOP kill -s SIGCONT

После SIGSTOP может быть побочный эффект - если приложение использовало консоль, то она должна оставаться в том режиме как её установили до SIGCONT, иначе приложению может поплохеть.

А оно работает с иксовыми приложениями? Пока вижу одно применение

Чего только люди не придумают, лишь бы не пользоваться полноценными виртуалками.

Ты не путай виртуализацию с изоляцией.

А нафига патчить пол ядра, когда то же самое значительно проще реализуется привычными виртуальными машинами?

Да не то же самое, говорят тебе. Виртуализация подразумевает накладные расходы на себя, работают разные операционные системы а одном и том же железе; изоляция с использованием контейнеров накладных расходов не добавляет, потому что контейнеры работают под управлением одного и того же ядра.

Расскажи, какие такие накладные расходы?
Старт виртуалки? У Интела был проект на основе KVM, там система за полсекунды стартовала. Производительность? На современных процессорах потери - считанные проценты. Память? С ballooning тоже не особо проблема.

Операционная система в виртуалке должна запуститься? Должна. Память ей нужна? Нужна. Больше виртуалок запускаешь -> больше памяти уходит чисто на каждую виртуализируемую ОС.

Эмулировать работу железа нужно? Нужно, прямого доступа к железу в общем случае нет.

Потом идёт всякая двойная работа планировщиков (планировщик в реальной ОС и планировщик в виртуализируемой ОС работают), это плюс лишние переключения контекста.

Тут потери, там потери - кто-то может себе это позволить, а кто-то не может. Грубо говоря, у меня на этих «считанных процентах» потери производительности может ещё один контейнер работать на высоконагруженном сервере.

Не. Слишком просто и привязано к ядру.

Захотел переехать на другой сервер --- взял и переехал.

И в каком месте у тебя будет нетривиальная настройка?

Ути-пути, мамкин админ локалхоста.

А теперь то же самое, но без разрыва сетевых соединений. Время пошло.

Да я и не спорю, что виртуалки работают медленнее чем хост-система. Ну выиграем мы немного в производительности, зато серьёзно проиграем в безопасности (в первую очередь), разнообразии ОС в контейнерах и потенциально стабильности. Собственно ни LXC, ни Docker не гарантируют полной изоляции контейнеров. Docker вообще решето, так как docker-демон всегда работает от рута и любая его уязвимость становится дырищей в безопасности.

Грубо говоря, у меня на этих «считанных процентах» потери производительности может ещё один контейнер работать на высоконагруженном сервере.

Числа, друг мой, числа.

Всё зависит от того, какую цель ты преследуешь. Разные цели - разные решения.

Хочешь поделиться ресурсами сервера со внешними клиентами (VPS, например) - юзай виртуалки, они тебе безопасность дадут, чтобы не похачили тебя злые юзвери.

Хочешь для своих внутренних нужд ресурсы сервера поделить и не потерять производительность - юзай контейнеры.

Так они по таймауту отвалятся. Шустрости ни в каком из случаев не будет. И если железо серверов идентичное, то все вполне себе заводится, божечка помогает (не знаю что да как для серваков с мульоном юзеров онлайн и тьмой сервисов, но для небольшой сети предприятия со стандартным набором ламп_пг_смб_ишокойчо - вполне себе). Время пришло.