2016-02-29 4 views
0

Я читал о режиме демона процесса на https://en.wikipedia.org/wiki/Daemon_%28computing%29#CreationИзменяется родительский процесс, необходимый при демонтизации процесса?

В строго техническом смысле, системный процесс Unix-подобных является демоном , когда родительский процесс завершается и демон присваивается INIT процесса (номер процесса 1) в качестве его родительского процесса и не имеет контрольного терминала . Однако, чаще всего, демоном может быть любой фоновый процесс , будь то дочерний процесс init или нет.

На Unix-подобной системе, общий метод для процесса, чтобы стать демон, когда процесс запускается из командной строки или из сценария в запуска, такие как сценарий инициализации или сценарий SystemStarter, включает :

  1. диссоциирующем от управляющего терминала
  2. Стать лидером сеанса
  3. стать лидером группового процесса
  4. Исполнительные как фоновая задача по forki ng и выход (один или два раза). Иногда требуется, чтобы процесс стал сессией . Он также позволяет родительскому процессу продолжить нормальное выполнение .
  5. Установка корневого каталога (/) в качестве текущего рабочего каталога, чтобы процесс не поддерживал использование какого-либо используемого каталога, который может находиться на смонтированной файловой системе (позволяющей ее размонтировать).
  6. Изменение бит полномочий в 0, чтобы позволить открытой(), Creat(), а другая операционной система требует, чтобы обеспечить свои собственные маски разрешения и не зависеть от UMASK вызывающего
  7. Заключительного все унаследованных файлы в то время выполнения, которые остаются открытыми родительским процессом, включая файловые дескрипторы 0, 1 и 2 для стандартных потоков (stdin, stdout и stderr). Обязательные файлы будут открыты позже.
  8. Используя лог, консоль, или/Dev/нуля в качестве стандартного ввода, стандартного вывода и стандартного потока ошибок

Если процесс запускается с помощью супер-демона сервера, таких как INETD, запуска программ или Systemd, демон супер-сервера будет выполнять те функции для процесса [5] [6] [7] (за исключением демонов старого стиля, а не , преобразованных для запуска под systemd и заданных как Type = forking [7] и " threaded "серверы датаграмм в inetd [5]).

  1. Есть шаг там, что изменения родительского процесса процесса быть daemonized? Мне кажется, что ни один из шагов не делает этого?

    Изменился родительский процесс, необходимый при демонтизации процесса?

  2. После изменения родительского процесса процесса (процесс не обязательно быть daemonized), процесс может быть связан с контролирующим TTY нового родительского процесса?(Цель этого вопроса заключается в ли «держать процесс диссоциированного из в управляющего терминала нового родительского процесса» является необходимым условием из «изменения родительского процесса процесса».)

См. Мой родственный вопрос https://unix.stackexchange.com/questions/266565/daemonize-a-process-in-shell

Спасибо.

+0

Используйте [демон (3)] (http://man7.org/linux/man-pages/man3/daemon.3.html) –

ответ

2

Родитель процесса Unix не может быть изменен самим процессом. Типичный метод создания демона включает вызов fork (который создает процесс, который станет демонами). Затем начальный процесс завершает работу, а новорожденный дочерний процесс будет наследоваться процессом init, который становится его новым родителем. Это обрабатывается на шаге 4. Единственное, что сделает init, это подождать, пока все дети будут уходить. init не имеет управляющего TTY, поэтому после унаследования init демон больше не может ассоциироваться с контрольным TTY. Основной причиной диссоциирования является предотвращение получения сигналами, генерируемыми TTY (зависаниями и контролем-C и т. Д.) От демона.

Есть два способа Демоны, как правило, выполняются:

  1. От сценария оболочки. Скрипт запускает исполняемый файл демона с оператором & в конце команды, чтобы поместить демона в фоновый режим, возможно с перенаправлением ввода-вывода, чтобы установить stdin, stdout и/или stderr демона, а затем выходит из демона без родитель. Запуск исполняемого файла из оболочки включает оболочку, выполняющую fork, за которой следует exec в дочернем процессе исполняемого файла, который будет запущен.

  2. Программа daemon имеет возможность демонтировать себя. При запуске с этой опцией он выполняет fork, а в дочернем процессе - exec с соответствующим набором аргументов. Родитель обычно выйдет после fork, так как работа, которую просили сделать, выполнена. Если это не так, дочернему процессу требуется дополнительный fork, чтобы дать ему родителя, который может выйти. NB: вот почему так много программ, которые обычно запускаются как демоны, можно запускать напрямую, не становясь демонами, опция «стать демоном» заставляет дочерний процесс закрывать stdin/stdout/stderr, а затем просто exec это собственный исполняемый файл без " стать демоном ".

+0

Благодаря. В первом способе запуска демонов «Сценарий запускает исполняемый файл демона с оператором & в конце команды, чтобы поместить демона в фоновый режим« разрешить родительскому », а затем выйти из демона без родителя»? Если я прав, то фоновая обработка процесса недостаточна, чтобы позволить родительскому процессу выйти без его выхода. Нам нужно отключить или nohup процесс, помимо того, что он будет создан, так что, когда его родительский выход выйдет, он не выйдет. – Tim

+0

Я никогда не обнаружил, что SIGHUP будет распространяться на детей, вероятно, потому, что '&' помещает дочерний процесс в свою собственную группу процессов, поэтому сигналы родителям не доставляются ребенку. Если у родителя был TTY в качестве stdin, stdin ребенка не перенаправлялся, и ребенок не закрывал stdin достаточно быстро, ребенок мог получить SIGHUP из TTY, если родительский элемент выходит из него и вызывает уничтожение TTY. Перенаправление stdin ребенка в/dev/null настолько автоматическим, что я не могу вспомнить последний раз, когда я столкнулся с этой проблемой, но это может произойти. –

Смежные вопросы