Как «перевести в спящий режим» процесс в Linux, сохранив его память на диск и позже восстановив?

Можно ли перевести процесс в спящий режим в Linux? Как и в режиме гибернации в ноутбуке, я бы записал всю память, используемую процессом, на диск, освободив оперативную память. А потом, позже, я могу «возобновить процесс», т. Е. Прочитать все данные из памяти и вернуть их в ОЗУ, и я смогу продолжить свой процесс?

Раньше я поддерживал CryoPID , программу, которая делает именно то, о чем вы говорите. Он записывает содержимое адресного пространства программы, VDSO, ссылки на файловые дескрипторы и состояния в файл, который впоследствии может быть восстановлен. CryoPID запускался, когда в самом Linux не было используемых хуков, и работал полностью из пользовательского пространства (фактически, он все еще работает, в зависимости от настроек вашего дистрибутива / ядра / безопасности).

Проблемы были (действительно) сокетами, ожидающими сигналами RT, многочисленными проблемами X11, реализацией getpid () кэширования glibc и многими другими. Рандомизация (особенно VDSO) оказалась непреодолимой для тех немногих из нас, кто работал над ней после того, как Бернард ушел от нее. Однако это было весело и стало темой нескольких магистерских диссертаций.

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

Я хотел бы разместить здесь обновление статуса по состоянию на 2014 год.

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

Первый, который я предлагаю, потому что мне больше повезло с его запуском, это CRIU, который выполняет контрольную точку / восстановление в основном в пользовательском пространстве и требует, чтобы для работы была включена опция ядра CONFIG_CHECKPOINT_RESTORE.

Checkpoint / Restore In Userspace или CRIU (произносится kree-oo, IPA: / krɪʊ /, русский: криу) - это программный инструмент для операционной системы Linux. С помощью этого инструмента вы можете заморозить работающее приложение (или его часть) и записать его на жесткий диск в виде набора файлов. Затем вы можете использовать файлы для восстановления и запуска приложения с того места, где оно было заморожено. Отличительная особенность проекта CRIU в том, что он в основном реализован в пользовательском пространстве.

Последний - DMTCP ; цитируя их главную страницу:

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

Также есть хорошая страница в Википедии по аргументу: Application_checkpointing

Упомянутые ответы ctrl-zв данном случае действительно говорят об остановке процесса с помощью сигнала SIGTSTP. Вы можете подать сигнал остановки с помощью kill:

kill -STOP <pid>

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

Если вы хотите снова разбудить его, используйте

kill -CONT <pid>

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

Проблема заключается в восстановлении потоков - файлов и сокетов, открытых программой.

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

Если бы вы переходили в спящий режим для каждой программы (без поддержки приложений), как бы вы обрабатывали открытые файлы? Что, если к этим файлам будет обращаться другой процесс? и т.д?

Поддерживать состояние, когда программа не загружена, будет сложно.

Просто приостановить потоки и разрешить их пересылку на диск иметь такой же эффект?

Или запустите программу на виртуальной машине и позвольте виртуальной машине обрабатывать приостановку.

Ядро Linux теперь частично реализовало фьючерсы контрольной точки / перезапуска: https://ckpt.wiki.kernel.org/ , статус здесь .

Некоторая полезная информация находится в lwn (еженедельная сеть Linux): http://lwn.net/Articles/375855/ http://lwn.net/Articles/412749/ ......

Так что ответ "ДА"

Короткий ответ - «да, но не всегда надежно». Проверьте CryoPID:

http://cryopid.berlios.de/

Открытые файлы действительно будут самой распространенной проблемой. CryoPID прямо заявляет:

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

Те же проблемы повлияют и на TCP-соединения, хотя CryoPID поддерживает tcpcp для возобновления соединения.

Краткий ответ - да." Вы могли бы начать с просмотра этого для некоторых идей: Реконструкция исполняемого файла ELF из основного образа ( http://vx.netlux.org/lib/vsc03.html )

Я расширил Cryopid, выпустив пакет Cryopid2, доступный на SourceForge. Это может переносить процесс, а также переводить его в спящий режим (вместе с любыми открытыми файлами и сокетами - данные в сокетах / каналах засасываются в процесс при спящем режиме и возвращаются в них при перезапуске процесса).

Причина, по которой я не участвовал в этом проекте, заключается в том, что я не являюсь разработчиком ядра - и этот (и / или исходный криопид) должен привлечь кого-то, кто сможет запустить их с новейшими ядрами (например, Linux 3.x) .

Метод Cryopid действительно работает - и, вероятно, это лучшее решение для гибернации / миграции процессов общего назначения в Linux, с которым я сталкивался.

Как отмечали другие, ОС трудно обеспечить эту функциональность, потому что приложение должно иметь встроенную проверку ошибок для обработки битых потоков.

Однако стоит отметить, что некоторые языки программирования и инструменты, использующие виртуальные машины, явно поддерживают эту функцию, например, язык самопрограммирования .

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

Было проведено некоторое исследование контрольной точки / восстановления для Linux еще через 2.2 и 2.4 дня, но оно так и не прошло мимо прототипа. Это возможно (с оговорками, описанными в других ответах) для определенных значений возможных - я могу написать модуль ядра для этого, это возможно. Но для обычного значения возможного (могу ли я сделать это из оболочки в коммерческом дистрибутиве Linux) это пока невозможно.

Это своего рода конечная цель кластерной операционной системы. Мэтью Диллон прилагает много усилий для реализации чего-то подобного в своем проекте Dragonfly BSD .

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

Если по какой-либо причине вам не нравится виртуальный бокс, вам подойдут vmware и Qemu.

Есть ctrl+zв Linux, но я не уверен, что он предлагает указанные вами функции. Я подозреваю, что вы задали этот вопрос, поскольку он не