Опубликован выпуск инструментария CRIU 3.19 (Checkpoint and Restore In Userspace), предназначенного для сохранения и восстановления процессов в пространстве пользователя. Инструментарий позволяет сохранить состояние одного или группы процессов, а затем возобновить работу с сохранённой позиции, в том числе после перезагрузки системы или на другом сервере без разрыва уже установленных сетевых соединений. Код проекта распространяется под лицензией GPLv2...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60199
Хорошая утилита. Пользовался одно время.
Жаль только с иксами не работает. И что-то затухла инициатива прикрутить к вейланду.
В смысле затухла? Прикрутили уже, что еще надо?
>Status: stalledЧто конкретно прикрутили?
>>Status: stalledЧто за статус?
> Что конкретно прикрутили?
В плазме 6 по идее можно без проблем сохранять и восстанавливать Qt-приложения. В других тулкитах никто поддержку и не планировал вроде.
Это статус поддержки вейланда в CRIU, с тех пор никаких новостей не было.
> Это статус поддержки вейланда в CRIU, с тех пор никаких новостей не
> было.Не знаю что за статус и где, в Qt пришло бесплатно как by-product поддержки переподключения к композитору
Тут не переподключение.
https://www.opennet.dev/openforum/vsluhforumID15/4888.html#35"глянуть сегодняшнюю подсистему засыпания в свап и востановления из сна. Идея: переодически сынкать изменённую память процесов на свап, если сынкать, только, изменения будет не много. В случае отключения питания загрузка производится как после засыпания в свап."
Да, серьезно упрощает жизнь сисадминам и девопсам.
Очень удобно делать снапшоты по расписанию для пользователей в твоей конторке. Потом находишь снапшот с открытым интернет-банком и переводишь себе на мороженное скромную или не очень сумму.
а там токен протух и кроме него у тебя ничего нет
158.3, пункт «г»; 159.3
Ну и потом не то что в эникейщики, в сторожа путь заказан
core dumped
>на другом сервере без разрыва уже установленных сетевых соединенийЭто как? Не говоря уже о том, что другая сторона порвёт просто по таймауту для практически значимых случаев.
Гугли на тему TCP_REPAIR_QUEUE, через него можно не только соединения процесса заморозить, но и сохранить соединения после мягкой перезагрузки ОС.https://lists.openwall.net/netdev/2012/03/28/84
https://lwn.net/Articles/495304/
То что восстановить на локальной системе можно - это понятно. Но вот представь, у тебя работающий сервер. Ты его замораживаешь, мигрируешь на другой VPS, размораживаешь. У него айпишник будет другой. Предположим, что у них хитрая реализация TCP, позволяющая менять айпишники в середине сессии. Более того, приложение в своих переменных будет хранить старый адрес, а значит все новые сессии на старый адрес прозрачно менять на новый. Но как они все узнают новый IP? А никак, в TCP такие финты не предусмотрены. Значит придётся это либо в протокол самого приложения, но тогда можно просто начать новую сессию с новым IP, и заменить адрес в переменных, как встроенная фича сервера. Тогда весь этот гимор с замораживаниями и хитрыми реализациями TCP не нужен. Делать навесной протокол без аутентификации? Злоумышленникам очень понравится. С аутентификацией? Не везде применимо, и код приложения менять надо. Далее, если миграция не пройдёт очень быстро, то клиенты отвалятся по таймауту.Отсюда, единственное применение этой технологии - микросервисная архитектура, когда у нового и старого инстанса микросервиса один и тот же айпишник внутри своей частной сети и когда все микросервисы настроены не рвать соединение по таймауту. Эрзац-servicemesh на костылях. Обычный сервисмеш лучше, но на самом деле ни сервисмеш, ни миаросервисная архитектура не нужны, это просто модный культ карго.
> У него айпишник будет другой.Не будет. Переносил так виртуалки на другой континент, вместе с айпишником. Таймауты для TCP сессий в популярных ОС сам нагуглишь, это домашка тебе такая. Как сделаешь, я тебе про сервисмеш домашку выдам. А там глядишь и до карго-культа доберёмся. Всё, топай самообразовываться.
Я не тот аноним, но тоже не понял что-то. Вот есть у меня приложение, которое установило соединение с сервисом в инете. Я его заморозил, а через день разморозил, и все продолжит работать что-ли? И там в инете целый день меня буду ждать?
Ну прямо день может и не будет, но вообще это зависит от многих факторов. В убогие времена модемной связи по карточкам можно было отключиться, пообедать, попить чаю, сходить в сортир и подключиться обратно, при этом SSH-сессии не рвались (если не пытаться в окне никакие кнопки нажимать, конечно же). Разгадка проста: публичный айпишник у провайдерского NATа был один на всех, поэтому с точки зрения удалённого сервера ничего страшного не происходило. RST не пришёл, а то, что пакетов полтора часа в сокете нет, так это ещё не повод рвать соединение. Если тебе в цифрах интересно, что смотри man 7 tcp, конкретно про логику работы keepalive.
Это конкретно один протокол так реализован и сервер так настроен. А остальные сервера (HTTP, кхе, кхе) просто порвут соединение, чтобы не было slowloris.
Собственно для миграции серверов, обслуживающих много пользователей, миграция контейнеров и нужна. Свой личный сервер перезапустить обычно проблемы нет. Перезапустить сервер массового обслуживания - у пользователей проблемы будут. Я не вижу, как замораживание их может решить. Обычно их решают так: стартуют новый заблаговременно на своём айпишнике, когда загрузится - балансировщик его задействует, после чего старый можно убирать. Так что миграция контейнеров и тут не нужна. Зачем нужно сохранение сетевых соединений при разморозке - не понятно.
Про keepalive я в курсе, но а если он не используется в протоколе, то что? Вот, к примеру, я сделал telnet IP 80, и он продолжит работать после нескольких через заморозки?
Ты (и другой анон выше тоже) путаешь уровни OSI. Гарантии CRIU ограничиваются TCP. Всё, что выше не его забота. Для HTTP он действительно мало полезен. Но HTTP-соединения by design долго не живут. К сожалению, Интернет не ограничивается одним HTTP.
Игрался с заморозкой софта, через несколько заморозок программа начала глючить. Слишком замутно, легче виртуалку со снапшотами использовать.
Предположу что сохраняется только память программы, а память ядра не сохраняется (например, открытые файлы), и CRIU пытается по частям выдрать эту инфу из ядра. В виртуалках же тупо сохраняется вся память в снимок (но только для qcow2 образов).
По-моему, с некоторых пор, оно пытается восстанавливать процессы под теми же идентификаторами, если они уже заняты, тут упс. Во всяком случае, это может быть одной из причин -- многое зависит от архитектуры приложения. У сетевых больше причин отвалиться, если подобные вещи не являются для них штатными (практически 100% софта умирает при минимальных отклонениях в подключении).
Лучше писать приложения, которые не нужно замораживать. Такая заморозка никогда полностью корректно работать не будет для приложения в общем случае.
Sigstop ещё запрети. Самому не смешно?