Как "спячить" процесс в Linux, сохранив его память на диске и восстановив его позже?
Возможно ли "спящий" процесс в Linux? Как и в "спящем режиме" на ноутбуке, я хотел бы записать всю память, используемую процессом, на диск, освободить оперативную память. А потом я могу "возобновить процесс", т. Е. Прочитать все данные из памяти и вернуть их в оперативную память, и я смогу продолжить процесс?
13 ответов
Я имел обыкновение поддерживать CryoPID, программу, которая делает именно то, о чем вы говорите. Он записывает содержимое адресного пространства программы, VDSO, ссылки на файловые дескрипторы и состояния в файл, который впоследствии может быть восстановлен. CryoPID запускался, когда в самом Linux не было пригодных для использования хуков, и работал полностью из пользовательского пространства (на самом деле, он все еще работает, в зависимости от настроек вашего дистрибутива / ядра / безопасности).
Проблемами были (в действительности) сокеты, ожидающие сигналы RT, многочисленные проблемы X11, реализация getpid() для кэширования glibc и многие другие. Рандомизация (особенно VDSO) оказалась непреодолимой для тех немногих, кто работал над ней после того, как Бернард ушел от нее. Однако это было весело и стало темой нескольких магистерских диссертаций.
Если вы просто рассматриваете программу, которая может сохранить свое рабочее состояние и перезапустить непосредственно в это состояние, гораздо проще… гораздо проще сохранить эту информацию из самой программы, возможно, при обслуживании сигнала.
Я хотел бы разместить здесь обновление статуса, начиная с 2014 года.
В принятом ответе CryoPID предлагается в качестве инструмента для выполнения Checkpoint/Restore, но я обнаружил, что проект не поддерживается и его невозможно скомпилировать с последними ядрами. Теперь я нашел два активно поддерживаемых проекта, обеспечивающих функцию проверки приложений.
Первый, который я предлагаю, потому что мне больше повезло с его запуском, это CRIU, который выполняет контрольную точку / восстановление в основном в пространстве пользователя и требует, чтобы опция ядра CONFIG_CHECKPOINT_RESTORE была включена.
Checkpoint / Restore In Userspace, или CRIU (произносится как kree-oo, IPA: /krɪʊ/, русский: криу), представляет собой программный инструмент для операционной системы Linux. Используя этот инструмент, вы можете заморозить работающее приложение (или его часть) и установить его на жесткий диск в виде набора файлов. Затем вы можете использовать файлы для восстановления и запуска приложения с той точки, в которой оно было заморожено. Отличительной особенностью проекта CRIU является то, что он в основном реализован в пространстве пользователя.
Последний является DMTCP; цитирование с их главной страницы:
DMTCP (распределенная многопоточная проверка) - это инструмент для прозрачной проверки состояния нескольких одновременных приложений, включая многопоточные и распределенные приложения. Он работает непосредственно с исполняемым пользователем двоичным файлом, без каких-либо модулей ядра Linux или других модификаций ядра.
Есть также хорошая страница Википедии с аргументом: http://en.wikipedia.org/wiki/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:
Открытые файлы действительно будут самой распространенной проблемой. CryoPID прямо заявляет:
Открытые файлы и смещения восстанавливаются. Временные файлы, которые не были связаны и недоступны в файловой системе, всегда сохраняются в образе. Другие файлы, которые не существуют в резюме, еще не восстановлены. Планируется поддержка сохранения содержимого файла для таких ситуаций.
Те же проблемы также влияют на TCP-соединения, хотя CryoPID поддерживает tcpcp для возобновления соединения.
Я расширил Cryopid, выпустив пакет под названием Cryopid2, доступный от SourceForge. Это может переносить процесс, а также переводить его в спящий режим (вместе с любыми открытыми файлами и сокетами - данные в сокетах / каналах засасываются в процесс при переходе в спящий режим и выплескиваются в них при перезапуске процесса).
Причина, по которой я не был активен в этом проекте, заключается в том, что я не являюсь разработчиком ядра - и для этого (и / или для оригинального cryopid) нужен кто-то, кто может запустить их с последними ядрами (например, Linux 3.x),
Метод Cryopid работает - и, вероятно, является лучшим решением для гибернации / миграции процессов общего назначения в Linux, с которыми я сталкивался.
Краткий ответ - да." Вы можете начать с рассмотрения некоторых идей: восстановление исполняемого файла ELF из образа ядра ( http://vx.netlux.org/lib/vsc03.html)
Как уже отмечали другие, для ОС трудно обеспечить эту функциональность, потому что приложение должно иметь некоторую встроенную проверку ошибок для обработки битых потоков.
Однако отметим, что некоторые языки программирования и инструменты, использующие виртуальные машины, явно поддерживают эту функцию, например язык программирования Self.
Добавление другого обходного пути: вы можете использовать виртуальный бокс. запускайте свои приложения на обычной виртуальной машине и просто "сохраняйте состояние машины", когда захотите. Я знаю, что это не ответ, но я подумал, что это может быть полезно, когда нет реальных вариантов.
Если по какой-либо причине вам не нравится виртуальный бокс, вам подойдут vmware и Qemu.
Это своего рода конечная цель кластерной операционной системы. Мэтью Диллон прилагает много усилий для реализации чего-то подобного в своем проекте Dragonfly BSD.
Было некоторое исследование по контрольной точке / восстановлению для Linux в 2.2 и 2.4 днях, но оно никогда не проходило мимо прототипа. Это возможно (с оговорками, описанными в других ответах) для определенных значений возможных - я могу написать модуль ядра, чтобы сделать это, это возможно. Но для общей ценности возможного (могу ли я сделать это из оболочки в коммерческом дистрибутиве Linux), это пока невозможно.
Ctrl-Z увеличивает вероятность того, что страницы процесса будут заменены, но это не освобождает ресурсы процесса полностью. Проблема с полным освобождением ресурсов процесса заключается в том, что такие вещи, как файловые дескрипторы, сокеты - это ресурсы ядра, которые процесс использует, но не знает, как его сохранить самостоятельно. Так что Ctrl-Z настолько хорош, насколько это возможно.
Там в ctrl+z в Linux, но я не уверен, что он предлагает функции, которые вы указали. Я подозреваю, что вы задали этот вопрос, так как он не