Ядро процесса дампа, не уничтожая процесс
Различие является главным образом историческим в этой точке, я полагаю, что некоторые системы даже имеют more и less hardlinked к тому же двоичному файлу.
Первоначально, more в значительной степени только разрешенный Вас для продвижения в файле, но было довольно достойно для буферизации вывода.
less был записан как улучшенный more это позволило Вам прокручивать вокруг отображаемого текста
Первая строка моего man less в значительной степени подводит итог его:
Less is a program similar to more, but which allows backward
movement in the file as well as forward movement.
Обычный прием должен иметь что-то (возможно сигнал как SIGUSR1) инициируйте программу к fork(), затем дочерние вызовы abort() заставить себя вывести ядро.
from os import fork, abort
(...)
def onUSR1(sig, frame):
if os.fork == 0:
os.abort
и во время инициализации
from signal import signal, SIGUSR1
from wherever import onUSR1
(...)
signal.signal(signal.SIGUSR1, wherever.onUSR1)
Используемый этот путь, fork не использует много дополнительной памяти, потому что почти все адресное пространство будет совместно использовано (который является также, почему это работает на генерацию дампа ядра).
Когда-то давно этот прием использовался с названной программой undump генерировать исполняемый файл от дампа ядра для сохранения образа после сложной инициализации; emacs используемый, чтобы сделать это для генерации предварительно загруженного изображения от temacs.
-
1В какой-то момент gcore был автономной программой, но я не думаю, что это - часть gdb пакета больше - однако можно выполнить gdb - pid = <PID> и затем использовать, это - команда gcore для дампа базового файла. gcore.c является довольно простой программой, которая легко googlable, если Вы хотите что-то более легкий вес. – synthesizerpatel 17.09.2014, 22:30