Вот бы из этого сделали штуку, чтобы я на десктопе закрыл приложение и открыл на том же месте с теми же документами и в том же состоянии, совсеми ундами и прочее. И чтобы созранялось это или локально или на сервере и на другом компе продолжить. Иногда так не хватает.

Этот проект в virtuozzo пилят, несколько я знаю.

Штука крутая и нужная.

Гуёвые проги оно научилось восстанавливать?

Это реинкарнация cryopid?

Да

О, оно похоже умеет сохранять и восстанавливать процессы, запущенные через mpi. Там даже как один из сценариев сохранение состояния числодробилки каждые N часов чтобы при сбое не потерять результаты длинных расчётов. Надо опробовать.

Судя по информации на wiki, если ещё не научилось, то собирается.

А восстановить расчеты на видео-картах оно может?

Интересно как люди это используют. Особенно если оно не поддерживает графические приложения. Возможно, одним из применений была бы прозрачная миграция задач в клауде (скажем, для балансировке), но работа с сокетами и их «восстановлением» лично у меня не внушает доверия.

У меня была задумка использовать cryopid для приложения которое долго инициализируется (чтобы можно было его быстро разморозить вместо нового запуска и инициализации), но оно не взлетело на моей системе.

https://xakep.ru/2017/05/30/virtuozzo-work-for-unixoid/#toc04.

Павел Емельянов, главный архитектор Virtuozzo

... расскажу историю появления CRIU. Изначально все модификации Virtuozzo не шли в основную ветку ядра (так называемый upstream) — то есть в ядро Linux. Они были открытыми, но это, по сути, у нас была своя собственная ветка ядра. В какой-то момент мы начали отправлять всю эту функциональность Линусу Торвальдсу. Так появились подсистемы cgroups и namespaces, которыми сейчас все пользуются. А еще был третий компонент — живая миграция, которая у нас была целиком в ядре. Чем-то похожим занимались не только мы, но и IBM и еще несколько исследователей из Колумбийского университета.

Несколько лет команда разработчиков ядра не принимала эти патчи: все говорили, что это слишком большая подсистема, которая выворачивает наизнанку все ядро. Вы, мол, пока работайте, но отдельно от нас. Постепенно мы стали вытаскивать некоторые компоненты наружу, в user space. То есть была утилита, которая дергала один-единственный вызов в ядре, типа восстановить или сохранить. Но вытащить все в user space невозможно, и мы продолжали писать патчи для ядра.

В какой-то момент Линусу все это надоело, и он сказал: «Все, дальше можете даже не пытаться, я это брать не буду». Тогда я решил попробовать вынести в пользовательское пространство максимум. И написал прототип, который впоследствии и превратился в CRIU. Не помню, сколько в нем было строк, но даже тысячи, кажется, не набиралось. Он сохранял и восстанавливал программку, которая работала с открытым файлом. У нее не было ни сокетов, ни пайпов, ни сигналов, никаких хитрых отображений в памяти — несколько небольших патчей для получения о процессе то ли памяти, то ли регистров и для создания процесса с заданным идентификатором (PID). Это можно было сделать в режиме отладчика, но тогда операции происходили бы побайтово, а мне была важна скорость. В общем, в результате появилось два патча и та малюсенькая программулинка. Народ посмотрел и решил, что это интересно — всего два патча, а возможностей открывается масса. Попросили развить эту идею.

Тут началась та же история, что и с попыткой занести все в ядро. Я добавил что-то еще — пайпы в том числе. Потом мне сказали: «Зачем тебе модифицировать proc-файл для доставания памяти, доставай как отладчик». Мы переделали это, я тогда подключил к работе еще одного сотрудника.

По сути, это был мой собственный проект, потому что в Virtuozzo никто не считал, что мой план сработает, а я тратил на это много времени. Мне советовали оставить это дело: раз не идет в ядро, значит, будем реализовывать при помощи модулей, нам не сложно. В общем, года два никто не принимал эту затею всерьез. А потом случился какой-то переломный момент.

На одной из конференций ко мне подошел один известный мейнтейнер ядра — Эндрю Мортон. Он спросил: «Долго вы еще будете всем этим заниматься-то? Может, релиз сделаете, я бы все эти патчи тогда взял и Линусу сдал в ядро». Они постоянно расширяют ядерный интерфейс, и наши наработки оказались бы полезными для всех.

Так мы сделали CRIU 0.1. Мортон влил патчи в ядро, об этом были написаны статьи, я выступил на конференции с докладом. Тогда в Virtuozzo поняли, что, видимо, мы наконец-то выкинем из нашего ядра checkpoint restore (это та самая живая миграция) и перейдем на мой вариант. Так CRIU перестал быть моим pet project и стал поддерживаться официально.

Ну что-ж, удачи парням. Но это как-то идёт в разрез с современной философией облаков (stateless, всё такое). Уверен, своя ниша у проекта найдётся («если пилят значит кому-то нужно»), но очень узкая, имхо.

За этим на Plan 9. :3

Хм, интересная вещь...

раз не идет в ядро, значит, будем реализовывать при помощи модулей, нам не сложно

А почему бы изначально не следовать этой идеи? Может кто-нибудь объяснить, зачем все пытаются протащить всё в ядро? Чем так плоха идея модульности?

Поддержка же

Может кто-нибудь объяснить, зачем все пытаются протащить всё в ядро?

Если втащить свой код в ядро, то его интерфейс постараются не сломать при следующем обновлении и воспевании мантры «stable API nonsense». Если не втащить, то даже стараться не станут.

Монолитный Linux

Чем так плоха идея модульности?

Идея-то хороша. Вот только на практике Linux — монолитное ядро. Развивать модуль вне ядра затратно, потому что в любой момент фоннаты «stable API nonsense», сломают API.

Ну вот у меня сервер, в нём драйвер проприетарный. Есть версии только для дистрибутивных ядер RHEL, Ubuntu 12.04, SLES. Причём даже не для всех версий, обновлю случайно ядро, а оно уже не загрузится. Если бы этот драйвер был в ядре, таких проблем не было бы в принципе: ставь что хочешь, обновляй что хочешь. Причём, очевидно, в какой-то момент разработчик перестанет обновлять этот драйвер и куча серверов останутся без обновлений, по сути можно только выкинуть и всё из за проприетарного драйвера.

Годный проект, очень годный. Рад, что проект развивается.

без разрыва уже установленных сетевых соединений

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

Вопрос от нуба: есть ли более низкоуровневые (например, аппаратные) реализации выгрузки абсолютно всего из озу (и еще наверно регистров) на диск и обратной загрузки?

Как-как... Берут - и восстанавливают сокеты с их состоянием. Они ж там возможность исполнения паразитного кода процессом в ядро пропихнули не просто так.

так клиенты то уже отвалились все

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

vmware? хибернейт в ноутах?

Вот бы из этого сделали штуку, чтобы я на десктопе закрыл приложение и открыл на том же месте с теми же документами и в том же состоянии, совсеми ундами и прочее. И чтобы созранялось это или локально или на сервере и на другом компе продолжить. Иногда так не хватает.

в общем случае, очень трудно реализуемо. одно дело процесс в памяти, и другое - какие еще ресурсы задействованы (файлы, сокеты, другие процессы, итдитп)

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

Как сохранение состояния виртуальной машины, только в железе.

без разрыва уже установленных сетевых соединений

А как такое вообще возможно? Соединение ведь может быть разорвано другой стороной, обнаружившей, что сервис не откликается, например. Или я чего-то не понимаю?

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

А может быть и не разорвано. У меня ssh-сессии спокойно работают после многочасовых суспендов ноутбука.

Интересно... Я думал, там какой-нибудь таймаут по неактивности стоит...

Насколько я помню, это настраивается киданием пустых пакетиков раз в нное число минут.

Облака - это маркетинговый проходняк. Сдохнут как и появились.

Примерно так же, как от перехода компьютера в оффлайн сетевое соединение не разрывалось сразу во времена диалапа.

По идее, если успеть до таймаута keep-alive, и если к примеру шлюз «знает», куда переехала виртуалка, то вполне возможно. Клиент получит лаг, но работа не прекратится.

Как-то так я это вижу.

Если втащить свой код в ядро, то его интерфейс постараются не сломать при следующем обновлении и воспевании мантры «stable API nonsense». Если не втащить, то даже стараться не станут.

А в ядре перенесут в staging, сделают видимость, что собирается, но гарантии, что оно работает всё равно не будет. Если посыпятся жалобы, что не работает, код просто вынесут из ядра.

Облака - это маркетинговый проходняк. Сдохнут как и появились.

У меня для тебя плохие новости :). Ну, сам увидишь со временем...

облака уже сдохли, лечись от аутизма

Удовлетвори моё любопытство, в чём удовольствие писать тот тупняк что ты написал? Тебе нравится называть других аутистами? Или у тебя какое-то заболевание типа синдрома Туретта, но в письменной форме?

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

Проходи мимо, здесь еды нет.

Краткая выжимка из https://criu.org/Usage_scenarios

• Живая миграция контейнеров-то для чего это создавалось. Контейнер зачекпоинтился, образ перенесли на другую машину, там восстановили. Как я понимаю, при этом сценарии «без разрыва сетевых соединений» подразумевается, что между выключением старого контейнера и включением нового должно пройти совсем немного времени, тогда это взлетит (юзер заметит просто кратковременное зависание). Думаю, это киллер-фича и хотя она ещё не откатана, но такого нет ни у кого насколько я знаю.
• Ускорение загрузки сервисов, которые обычно загружаются не быстро. Например, мы делаем чекпоинт в точке, когда сервис уже стартанул, затем при необходимости просто запускаем сервис из чекпоинта вместо запуска его с нуля. Например, VNC сервер+эклипс удалось запустить за 1.5 секунды вместо 30, это грубая оценка и все цифры взяты с сайта разработчика.
• Бесшовное обновление ядра-тут я не осилил перевести, так как не знаю, что такое kexec

  When replacing a kernel on a box we can do it without stopping critical activity. Checkpoint it, then replace the kernel (e.g. using kexec) then restore services back. In a perfect world the applications memory shouldn't be put to disk image, but should rather be kept in RAM.
  

• Балансировка сетевой нагрузки. Кусок проекта, который отвечает за TCP repair можно использовать, чтобы перераспределить запросы на уровне приложения на другой сервер.
• High Performance Computing — опять-таки распределение нагрузки и своеобразные бэкапы
• Сохранение в играх, где сохранений нет.
• Дебаг продакшена без ущерба для продакшена (содрал процесс в другую виртуалку и насилуй его как хош)

Вроде как что-то и для иксов планируется, но будет делаться скорее всего в последнюю очередь, т.к. сложность Х-сервера и комерчески малоинтересно.

Облака - это маркетинговый проходняк. Сдохнут как и появились.

Боюсь, что ты не прав. Маркетинговое говно - да, но это тот сорт говна, который слишком выгоден корпорациям.

Да, идеи подобного вбрасываются аж с конца 90-х, но до определённого момента сети были недостаточно быстрыми, а процессоры недостаточно мощными. А сейчас всё, процесс пошёл, и остановить его будет крайне тяжело. Первым звоночком были веб-интерфейсы к почте, которые практически вытеснили «толстые клиенты». Потом пошли всякие гуглодоксы.

А теперь уже попёрли онлайн-видеоредакторы, и это означает, что всё - дно пробито.

закрыл приложение и открыл на том же месте с теми же документами и в том же состоянии, совсеми ундами и прочее

В Vim это давно уже есть.

Здо́рово. А в нём можно уже фотки обрабатывать, чертить и снимать фильмы?

фотки обрабатывать, чертить и снимать фильмы

Может это уже есть в Emacs?

Годно, в DragonFlyBSD такая фишка из коробки

Годно, в DragonFlyBSD такая фишка из коробки

пруфы?

jollheef, иди нахуй.

пруфы?

http://www.dragonflybsd.org/release48/

Все здесь.

по какому ключевому слову искать?