Что именно означает запуск процесса в “фоновом” режиме?

Я хочу немного лучше понять, что такое фоновый процесс. Вопрос возник в результате прочтения этой строки кода:

/usr/sbin/rsyslogd -niNONE &

Источник

Документация говорит:

  -i pid file
         Укажите альтернативный файл pid вместо файла по умолчанию.
         Этот параметр необходим, если на одной машине
         должны работать несколько экземпляров rsyslogd. Чтобы отключить
         запись в файл pid, используйте зарезервированное имя "NONE"
         (все заглавные буквы!), то есть "-iNONE".

  -n     Избегайте автоматического фонового режима. Это особенно важно,
         если rsyslogd запускается и управляется init(8).

Источник

Амперсанд &, похоже, означает, что команда должна выполняться в фоновом режиме, см. например здесь.

Если я правильно понимаю, файлы pid используются с демонами, то есть когда программа выполняется в фоновом режиме.

На первый взгляд кажется, что команда сначала говорит программе не работать в фоновом режиме с помощью -n, затем указывает NONE для файла pid, чтобы указать, что это не демон¹, а затем сразу после этого указывает & для отправки в фоновый режим.

Я не могу многое в этом понять. Фоновый режим, в который процесс обычно входит, отличается от того, в который его отправляют с помощью &? Из всего, что я прочитал, кажется, что единственное значение фонового режима заключается в том, что оболочка не блокируется. В этом отношении, просить процесс не уходить в автоматический фоновый режим и затем отправлять его в фоновый режим, не имеет большого смысла.

Здесь я что-то упускаю? Что именно такое фоновый режим? (И кто отвечает за удаление файла pid, раз уж на то пошло?)

¹ – в контексте контейнера Docker, откуда возник вопрос, наличие файла pid может вызвать проблемы при остановке и повторном запуске контейнера. Мне не ясно, кто отвечает за удаление файлов pid, некоторые источники предполагают, что это система инициализации, такая как systemd, тогда как другие полагают, что это обязанность программы. Однако, если процесс убит с помощью SIGKILL, программа может не иметь возможности удалить его, так что последующие перезапуски контейнера не удастся, потому что файл pid уже будет существовать, хотя его не должно быть.

Концепция фонового процесса в Unix является частью управления заданиями. Управление заданиями — это организация процессов вокруг терминальной сессии.

Демоны обычно не работают в терминальной сессии, поэтому они не являются фоновыми процессами в смысле управления заданиями Unix, а лишь в общем компьютерном смысле принадлежат к “невидимой” активности машины. Скорее всего, это то, что документ rsyslogd имеет в виду: он говорит о становлении демоном, а не о фоновом процессе управления заданиями.

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

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

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

Группа процессов переднего плана не только может читать и записывать в терминал, но и получает сигналы, генерируемые TTY, такие как SIGINT от CtrlC, и SIGTSTP от CtrlZ.

Обычно вы используете CtrlZ, чтобы приостановить задание в фоновом режиме, а затем команду управления заданиями, такую как bg, чтобы запустить его в фоновом режиме.

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

Теперь вы можете ввести bg, и оболочка заставит приостановленное фоновое задание выполняться.

Команда fg заставляет оболочку удалять себя из переднего плана и помещать фоновое задание в передний план снова.

Фоновые задания не получают сигналы, связанные с вводом символов с TTY, такие как SIGINT от CtrlC. Однако, когда они пытаются читать или записывать в терминал, они получают сигнал, такой как SIGTTOU, и становятся заблокированными для этого действия.

Управление заданиями — это как регулировщик движения, контролирующий доступ к терминалу.

Это похоже на то, чем является управление окон в графическом интерфейсе пользователя (GUI). В обычной графической оболочке одно окно имеет “фокус клавиатуры”. Ввод с клавиатуры поступает в это окно. Так и с управлением заданиями: группа процессов переднего плана имеет “фокус терминала”, так сказать.

Документация rsyslogd, почти наверняка, использует термин “фон” в значении “превратиться в демон” или “демонизироваться”. Это отличается от “фонового задания” в рамках управления заданиями POSIX.

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

Имеет смысл, что rsyslogd не демонизируется, если запускается init, так как нет терминальной сессии, от которой нужно отвязываться. (Однако, rsyslogd мог бы обнаруживать, что он не является частью терминальной сессии, и не требовать флага -n в такой ситуации.)

Таким образом, фактически основным использованием параметра командной строки, запрещающего демонизацию в сервере, будет отладка, с конкретными причинами, такими как:

• Возможно, у демона есть режим отладки, при котором сообщения отправляются на стандартный выход. Если вы хотите наблюдать за этими сообщениями на своей консоли, вам не нужно, чтобы демон закрывал его файловый дескриптор выхода.

• Если вы хотите отлаживать демона с помощью отладчика, это неудобно, если он просто завершает работу, так что фактическая деятельность демона происходит в порожденном внуке.

• Когда вы тестируете, возможно, вы захотите использовать управление заданиями над демоном, например, завершить его с помощью CtrlC, или приостановить с помощью CtrlZ.

• Иногда люди любят запускать серверы в терминальном мультиплексирующем программном обеспечении, таком как GNU Screen или Termux, где серверы работают в терминальной сессии. Авто-демонизация противоречила бы цели этого.

Что касается того, кто отвечает за удаление файла PID: в основном, само приложение сервиса, если оно корректно завершает работу. Если какой-то основной процесс управляет сервисами, он может знать о путях к их файлам PID и очищать их, если они завершаются без удаления файла. Файлы PID обычно размещаются в каталоге, который очищается при перезагрузке, например /var/run, так что если система катастрофически отказывает и должна быть перезагружена, перезагрузка позаботится о файлах PID.

Для полноты картины следует упомянуть, что в программировании оболочки есть концепция фонового режима, отличная от интерактивного управления заданиями POSIX. Даже в оболочке без управления заданиями или в неинтерактивном сценарии мы можем запускать задания параллельно, используя оператор &, и ждать их завершения с помощью wait. Когда оболочка управления заданиями используется интерактивно, & интегрируется с управлением заданиями: нет разницы между запуском команды в фоновом режиме с & и ее обычным выполнением с последующим переводом в фоновый режим с помощью CtrlZ и bg. Механизм & работает и вне контекста интерактивного управления заданиями, но его все же можно обсуждать, используя риторику “фонового режима”.