Можете ли вы заморозить процесс C / C ++ и продолжить его на другом хосте?

Question

Мне было интересно, можно ли сгенерировать файл "core", скопировать его на другой компьютер и продолжить выполнение файла core на этом компьютере?

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

Есть ли способ просто сбросить кучу / стек и восстановить их на более позднем этапе?

Answer 1

это называется миграция процесса .

mosix и OpenMosix раньше могли это делать. в настоящее время проще всего перенести целую виртуальную машину.

Answer 2

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

Answer 3

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

Answer 4

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

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

Тем не менее, CryoPID пытается сделать именно это и иногда успешно.

Answer 5

По состоянию на февраль 2017 года появился довольно стабильный и зрелый инструмент под названием CRIU , который зависит от обновлений ядра Linux, сделанных в версии 3.11 (как это было сделано в сентябре 2013 года, на большинстве современных должны быть включены в их версии ядра).

Его можно установить через aptitude, просто позвонив sudo apt-get install criu.

Инструкции по его использованию.

Answer 6

В некоторых случаях это можно сделать. Например, частью процесса сборки Emacs является загрузка всех библиотек Lisp, а затем выгрузка образа памяти на диск для быстрой загрузки. Некоторые другие языковые интерпретаторы тоже делают это (в основном я имею в виду реализацию Lisp и Scheme). Тем не менее, они специально разработаны для такого использования, поэтому я не знаю, что они должны делать, чтобы это работало.

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

Ответы других людей о виртуализации тоже на месте.

Answer 7

Есть много причин, по которым вы не можете делать то, что хотите, очень легко. Например, когда вы восстанавливаете основной файл на другом компьютере, как вы разрешаете открытые дескрипторы файлов, которые вы обрабатывали? А как насчет сокетов, именованных каналов, семафоров или любого другого ресурса уровня ОС? По сути, если ваша система специально не предназначена для выполнения такой операции, вы не сможете наивно сбросить файл ядра и перенести его на другой компьютер.

Answer 8

Зависит от машины. Это очень выполнимо, например, в очень маленькой встроенной системе. Я думаю, что это также реализовано в кластерах Beowulf и других суперкомпьютерных приложениях.

Answer 9

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