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

Question

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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

kill -STOP <pid>

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

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

kill -CONT <pid>

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

Answer 4

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

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

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

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

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

Или запустите программу на виртуальной машине и дайте ВМ справиться с приостановкой.

Answer 5

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

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

Итак, ответ «ДА»

Answer 6

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

http://cryopid.berlios.de/

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

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

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

Answer 7

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

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

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

Answer 8

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

Answer 9

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

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

Answer 10

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