Возможно ли "спящий" процесс в Linux? Так же, как "hibernate" в ноутбуке, я бы записал всю память, используемую процессом на диск, освободить оперативную память. И потом, я могу "возобновить процесс", т.е. Читая все данные из памяти и вернув их в ОЗУ, и я могу продолжить свой процесс?
Как "спящий" процесс в Linux, сохраняя его память на диске и восстанавливая ее позже?
Ответ 1
Я использовал CryoPID, который является программой, которая делает именно то, о чем вы говорите. Он записывает содержимое адресного пространства программы, VDSO, ссылки на дескрипторы файла и состояния в файл, который впоследствии может быть восстановлен. CryoPID начался, когда в самой Linux не было доступных крючков и полностью работало из пользовательского пространства (на самом деле он все еще работает, в зависимости от ваших настроек distro/kernel/security).
Проблемы были (действительно) сокеты, ожидающие сигналы RT, многочисленные проблемы X11, реализация glipping caching getpid() среди многих других. Рандомизация (особенно VDSO) оказалась непреодолимой для тех немногих из нас, кто работал над ней после того, как Бернард отошел от нее. Однако это было весело и стало темой нескольких тезисов.
Если вы просто задумываетесь о программе, которая может сохранить свое рабочее состояние и снова начать прямо в это состояние, то далеко не все... проще просто сохранить эту информацию из самой программы, возможно, при обслуживании сигнала.
Ответ 2
Я хотел бы поместить обновление статуса здесь, начиная с 2014 года.
Принятый ответ предлагает CryoPID как инструмент для выполнения Checkpoint/Restore, но я обнаружил, что проект будет невозможен и невозможно скомпилировать с последними ядрами. Теперь я нашел два активно поддерживаемых проекта, обеспечивающих функцию контрольной точки приложения.
Во-первых, тот, который я предлагаю, потому что мне лучше повезло, это CRIU который выполняет контрольную точку/восстановление в основном в пользовательском пространстве и требует, чтобы работала опция ядра CONFIG_CHECKPOINT_RESTORE.
Контрольная точка/восстановление в пользовательском пространстве или CRIU (произносится как kree-oo, IPA:/krɪʊ/, Russian: криу), является программным инструментом для операционной системы Linux. Используя этот инструмент, вы можете заморозить запущенное приложение (или его часть) и передать его на жесткий диск в виде набора файлов. Затем вы можете использовать файлы для восстановления и запуска приложения с момента его замораживания. Отличительной особенностью проекта CRIU является то, что он в основном реализован в пользовательском пространстве.
Последний DMTCP; цитируя со своей главной страницы:
DMTCP (Distributed MultiThreaded Checkpointing) - это инструмент для прозрачной проверки состояния нескольких одновременных приложений, включая многопоточные и распределенные приложения. Он работает непосредственно на двоичном исполняемом файле пользователя без каких-либо модулей ядра Linux или других модификаций ядра.
В аргументе также есть хорошая страница Википедии: Application_checkpointing
Ответ 3
Ответы, упоминающие ctrl-z, действительно говорят об остановке процесса с сигналом, в данном случае SIGTSTP. Вы можете выдать сигнал останова с помощью kill:
kill -STOP <pid>
Это приостановит выполнение процесса. Он не сразу освободит память, используемую им, но поскольку память требуется для других процессов, память, используемая остановленным процессом, будет постепенно заменена.
Если вы хотите снова разбудить его, используйте
kill -CONT <pid>
Более сложные решения, такие как CryoPID, действительно необходимы только в том случае, если вы хотите, чтобы остановленный процесс смог выдержать остановку/перезапуск системы - это не похоже на то, что вам нужно.
Ответ 4
Проблема заключается в восстановлении потоков - файлов и сокетов - что программа открыта.
Когда вся ваша ОС спячка, локальные файлы и т.д., очевидно, могут быть восстановлены. Сетевые подключения не выполняются, но тогда код, который обращается к Интернету, как правило, больше проверяет ошибки и, таким образом, выживает в условиях ошибки (или должен).
Если вы выполняли спящий режим для каждой программы (без поддержки приложения), как бы вы обрабатывали открытые файлы? Что делать, если другой процесс обращается к этим файлам в промежуточный период? и т.д.?
Сохранение состояния, когда программа не загружена, будет затруднительной.
Простое приостановление потоков и возможность его замены на диск будут иметь такой же эффект?
Или запустите программу на виртуальной машине и разрешите приостановление VM.
Ответ 5
Короткий ответ "да, но не всегда надежно". Проверьте CryoPID:
Открытые файлы действительно будут самой распространенной проблемой. CryoPID явно указывает:
Восстановлены файлы и смещения. Временные файлы, которые были несвязаны и недоступны на файловая система всегда сохраняется в образ. Другие файлы, которые не существуют на резюме еще не восстановлены. Поддержка сохранения содержимого файла для такие ситуации планируются.
Те же проблемы также влияют на TCP-соединения, хотя CryoPID поддерживает tcpcp для возобновления соединения.
Ответ 6
Ядро Linux теперь частично реализовало фьючерсы контрольной точки/перезагрузки: https://ckpt.wiki.kernel.org/, статус .
Некоторая полезная информация содержится в lwn (еженедельная сеть linux): http://lwn.net/Articles/375855/ http://lwn.net/Articles/412749/......
Итак, ответ "ДА"
Ответ 7
Короткий ответ - "да". Вы можете начать с рассмотрения некоторых идей: Реализация ЭЛП с основного образа (http://vx.netlux.org/lib/vsc03.html)
Ответ 8
Я расширил Cryopid, выпустив пакет Cryopid2, доступный от SourceForge. Это может перенести процесс, а также спящий режим (вместе с любыми открытыми файлами и сокетами - данные в гнездах/трубах всасывается в процесс при спящем режиме и впадает обратно в них, когда процесс перезапускается).
Причина, по которой я не был активен в этом проекте, я не разработчик ядра - оба этому (и/или оригинальному криопиду) необходимо, чтобы кто-то на борту, кто может заставить их бежать с последними ядрами (например, Linux 3.x).
Метод Cryopid действительно работает - и, вероятно, это лучшее решение для процесса общего назначения спящий режим/миграция в Linux. Я столкнулся.
Ответ 9
Как отмечали другие, для ОС этой функции сложно обеспечить такую функциональность, потому что приложение должно иметь встроенную встроенную проверку ошибок для обработки разбитых потоков.
Однако, с одной стороны, некоторые языки программирования и инструменты, которые используют виртуальные машины, явно поддерживают эту функциональность, например язык самопрограммирования.
Ответ 10
Там ctrl+z в linux, но я не уверен, что он предлагает функции, которые вы указали. Я подозреваю, что вы задали этот вопрос, так как он не
Ответ 11
Ctrl-Z увеличивает вероятность того, что страницы процесса будут заменены, но не полностью освободит ресурсы процесса. Проблема с полным освобождением ресурсов процесса заключается в том, что такие вещи, как дескрипторы файлов, сокеты - это ресурсы ядра, которые процесс получает использовать, но не знает, как упорствовать сам по себе. Таким образом, Ctrl-Z так же хорош, как и он.
Ответ 12
Было проведено некоторое исследование по контрольной точке/восстановлению для Linux в 2,2 и 2,4 дня, но оно никогда не проецировало прототип. Возможно (с оговорками, описанными в других ответах) для определенных значений возможного - я могу написать модуль ядра, чтобы это сделать, это возможно. Но для общей ценности возможного (могу ли я сделать это из оболочки в коммерческом дистрибутиве Linux), это еще не возможно.
Ответ 13
Это своего рода конечная цель кластерной операционной системы. Мэтью Диллон прилагает много усилий, чтобы реализовать что-то подобное в своем проекте Dragonfly BSD.