Як "перезимувати" процес у Linux, зберігаючи його пам'ять на диску та відновлюючи його згодом?

Чи можна «перезимувати» процес в Linux? Так само, як "сплячий" в ноутбуці, я б записав всю пам'ять, яку використовував процес, на диск, звільнивши оперативну пам'ять. А потім пізніше я можу "відновити процес", тобто прочитати всі дані з пам'яті і повернути їх в оперативну пам'ять, і я можу продовжувати процес?

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

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

Якщо ви просто розглядаєте програму, яка може зберегти її запущений стан і перезапустити безпосередньо в цей стан, його далеко .. набагато простіше просто зберегти цю інформацію всередині самої програми, можливо, під час обслуговування сигналу.

Я хотів би розмістити тут оновлення статусу станом на 2014 рік.

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

Перший, той, що я пропоную, тому що мені пощастило керувати ним, це CRIU, який виконує контрольну точку / відновлення в основному в просторі користувачів і вимагає, щоб параметр ядра CONFIG_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, дійсно потрібні лише в тому випадку, якщо ви хочете, щоб зупинений процес зміг пережити відключення / перезапуск системи - це не здається, що вам це потрібно.

Проблема полягає у відновленні потоків - файлів і сокетів - у відкритій програмі.

Коли вся ваша ОС сплять, локальні файли та інше, очевидно, можна відновити. Мережеві з’єднання не мають, але тоді код, який звертається до Інтернету, як правило, більше перевіряє помилки і такий і переживає умови помилок (або повинні).

Якби ви зробили сплячку за програмою (без підтримки додатків), як би ви обробляли відкриті файли? Що робити, якщо інший процес отримує доступ до цих файлів у проміжку часу? тощо?

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

Просто призупинення потоків і надання можливості його заміни на диск матиме такий же ефект?

Або запускайте програму у віртуальній машині і нехай VM обробляє підвіску.

Коротка відповідь - «так, але не завжди надійно». Перевірте CryoPID:

http://cryopid.berlios.de/

Відкриті файли справді будуть найпоширенішою проблемою. CryoPID прямо заявляє:

Відкриті файли та компенсації відновлюються. Тимчасові файли, від’єднані та недоступні у файловій системі, завжди зберігаються на зображенні. Інші файли, які не існують у резюме, ще не відновлені. Планується підтримка збереження вмісту файлів для таких ситуацій.

Ці самі проблеми також стосуватимуться TCP-з'єднань, хоча CryoPID підтримує tcpcp для відновлення з'єднання.

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

Деякі корисні відомості є у lwn (linux тижнева мережа): http://lwn.net/Articles/375855/ http://lwn.net/Articles/412749/ ......

Тож відповідь "ТАК"

Коротка відповідь - «так». Ви можете почати, вивчивши для цього кілька ідей: реконструкція виконуваної 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 .

додавання іншого вирішення: ви можете використовувати virtualbox. запускайте свої програми на звичайній віртуальній машині та просто "зберігайте стан машини" коли завгодно. Я знаю, що це не відповідь, але я вважав, що це може бути корисним, коли немає реальних варіантів.

якщо з будь-якої причини вам не подобається virtualbox, vmware та Qemu такі ж хороші.

Є ctrl+zв Linux, але я не впевнений, що він пропонує вказані вами функції. Я підозрюю, що ви задали це питання, оскільки це не так