it-swarm.com.ru

Ссылка для правильной обработки файла PID в Unix

Где я могу найти уважаемую ссылку которая подробно описывает правильную обработку файлов PID в Unix?

В операционных системах Unix обычной практикой является «блокировка» программы (часто демона) с помощью специального файла блокировки: файла PID.

Это файл в предсказуемом месте, часто "/var/run/foo.pid". Предполагается, что при запуске программа проверяет, существует ли файл PID, и, если файл существует, завершается с ошибкой. Так что это своего рода консультативный механизм совместной блокировки.

Файл содержит одну строку текста, представляющую собой числовой идентификатор процесса (отсюда и название «файл PID») процесса, который в данный момент удерживает блокировку; это позволяет легко автоматизировать отправку сигнала процессу, который удерживает блокировку.

Чего я не могу найти, так это хорошего справочника по ожидаемому или «лучшему практическому» поведению при работе с PID-файлами. Существуют различные нюансы: как на самом деле заблокировать файл (не беспокоиться? Использовать ядро? Как насчет несовместимости платформ?), Обрабатывать устаревшие блокировки (безмолвно удалять их? Когда проверять?), Когда именно получить и снять блокировку , и так далее.

Где я могу найти уважаемую, наиболее авторитетную ссылку (в идеале на уровне В. Ричарда Стивенса) для этой небольшой темы?

58
bignose

Насколько я знаю, PID-файлы - это соглашение, а не то, что вы можете найти уважаемый, в основном авторитетный источник. Самое близкое, что я мог найти, это этот раздел стандарта иерархии файловой системы.

Эта библиотека Perl может быть полезна, так как похоже, что автор, по крайней мере, задумался над некоторыми проблемами, которые могут возникнуть.

Я считаю, что файлы в/var/run часто обрабатываются сопровождающими дистрибутива, а не авторами демонов, так как ответственные за дистрибутив несут ответственность за то, чтобы все сценарии инициализации проигрывали Nice вместе. Я проверил документацию разработчиков Debian и Fedora и не смог найти подробных рекомендаций, но вы могли бы получить больше информации в списках рассылки их разработчиков.

17
Josh Kelley

Во-первых, во всех современных UNIX /var/run не сохраняется после перезагрузок.

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

Существует два канонических способа атомарного создания/проверки файла. Основным в наши дни является его открытие с флагом O_EXCL: если файл уже существует, вызов не выполняется. Старый способ (обязательный для систем без O_EXCL) заключается в создании его со случайным именем и ссылкой на него. Ссылка не удастся, если цель существует.

21
Joshua

См. Kerrisk's Интерфейс программирования Linux , раздел 55.6 "Запуск всего одного экземпляра программы" , который основан на реализации pidfile в Unix Network Programming Стивенса, v2.

Также обратите внимание, что расположение pid-файла обычно обрабатывается дистрибутивом (с помощью скрипта init), поэтому хорошо написанный демон примет аргумент командной строки для указания pid-файла и не допустит случайного переопределения файла конфигурации. Он также должен изящно обрабатывать устаревший файл pid (O_EXCL не должен использоваться). Следует использовать блокировку файлов fcntl () - вы можете предположить, что pid-файл демона находится в локальной (не NFS) файловой системе.

11
John Hammond

В зависимости от дистрибутива, это фактически скрипт инициализации, который обрабатывает pid-файл. Он проверяет существование при запуске, удаляет при остановке и т.д. Мне не нравится делать это таким образом. Я пишу свои собственные сценарии инициализации и обычно не использую стандартные функции инициализации.

Хорошо написанная программа (демон) будет иметь какой-то файл конфигурации, в котором будет указано, где должен быть записан этот pid-файл (если есть). Он также позаботится о том, чтобы установить обработчики сигналов, чтобы файл PID очищался при нормальном или ненормальном выходе при любой обработке сигнала. Затем файл PID дает сценарию инициализации правильный PID, чтобы его можно было остановить.

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

Что касается пространства имен, оно должно следовать за именем программы. Если вы запускаете 'foo-daemon', это будет foo-daemon.pid

Вам также следует изучить/var/lock/subsys, однако он используется в основном в версиях Red Hat.

7
Tim Post

Пакет systemd в Red Hat 7 предоставляет справочную страницу daemon(7) со строкой заголовка «Написание и упаковка системных демонов».

На этой странице руководства обсуждается демонизация «старого стиля» (SysV) и «нового стиля» (systemd). В новом стиле systemd сама обрабатывает PID-файлы для вас (если так настроено). Тем не менее, в старом стиле, страница руководства имеет следующее:

  1. В процессе демона напишите PID демона (как возвращено getpid ()) в файл PID, например /run/foobar.pid (для гипотетического демона "foobar"), чтобы гарантировать, что демон не может быть запущен более одного раза . Это должно быть реализовано без гонки, чтобы PID-файл был обновляется только тогда, когда проверяется в то же время, что PID ранее сохраненный в файле PID больше не существует или принадлежит чужой процесс.

Вы также можете прочитать эту справочную страницу онлайн .

0
Wildcard