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

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

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

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

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

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

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

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

Что касается пространства имен, оно должно следовать за именем программы. Если вы начинаете "пищу (foo daemon)", это будет food.pid

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