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

можно ли "спящий режим" процесс в linux? Так же, как "спящий режим" в ноутбуке, я бы написал всю память, используемую процессом на диск, освободите ОЗУ. А потом я смогу "возобновить процесс".e, читая все данные из памяти и возвращая их в ОЗУ, и я могу продолжить свой процесс?

13 ответов


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

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

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


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

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

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

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

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

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

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


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

kill -STOP <pid>

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

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

kill -CONT <pid>

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


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

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

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

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

просто приостановить потоки и позволить ему переключиться на диск будет иметь такой же эффект?

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


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

http://cryopid.berlios.de/

Open files действительно будет самой частой проблемой. Штаты CryoPID в явном виде:

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

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


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

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

таким образом, ответ "да"


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


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

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

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


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

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


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


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


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


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