ссылка для правильной обработки файла pid в unix

<p>где я могу найти<strong> уважаемую ссылку </strong>которая подробно описывает правильную обработку файлов pid в unix?</p><p>в операционных системах unix обычной практикой является «блокировка» программы (часто демона) с помощью специального файла блокировки: файла pid.</p><p>это файл в предсказуемом месте, часто "/var/run/foo.pid". предполагается, что при запуске программа проверяет, существует ли файл pid, и, если файл существует, завершается с ошибкой. так что это своего рода консультативный механизм совместной блокировки.</p><p>файл содержит одну строку текста, представляющую собой числовой идентификатор процесса (отсюда и название «файл pid») процесса, который в данный момент удерживает блокировку; это позволяет легко автоматизировать отправку сигнала процессу, который удерживает блокировку.</p><p>чего я не могу найти, так это хорошего справочника по ожидаемому или «лучшему практическому» поведению при работе с pid-файлами. существуют различные нюансы: как на самом деле заблокировать файл (не беспокоиться? использовать ядро? как насчет несовместимости платформ?), обрабатывать устаревшие блокировки (безмолвно удалять их? когда проверять?), когда именно получить и снять блокировку , и так далее.</p><p>где я могу найти<strong> уважаемую, наиболее авторитетную ссылку </strong>(в идеале на уровне в. ричарда стивенса) для этой небольшой темы?</p>

<p>насколько я знаю, pid-файлы - это соглашение, а не то, что вы можете найти уважаемый, в основном авторитетный источник. самое близкое, что я мог найти, это <a href="http://www.pathname.com/fhs/2.2/fhs-5.13.html">этот раздел</a> стандарта иерархии файловой системы.</p><p> <a href="http://search.cpan.org/~ecalder/proc-pid-file/">эта библиотека perl</a> может быть полезна, так как похоже, что автор, по крайней мере, задумался над некоторыми проблемами, которые могут возникнуть.</p><p>я считаю, что файлы в/var/run часто обрабатываются сопровождающими дистрибутива, а не авторами демонов, так как ответственные за дистрибутив несут ответственность за то, чтобы все сценарии инициализации проигрывали nice вместе. я проверил документацию разработчиков debian и fedora и не смог найти подробных рекомендаций, но вы могли бы получить больше информации в списках рассылки их разработчиков.</p>

<p>во-первых, во всех современных unix <code>/var/run</code> не сохраняется после перезагрузок.</p><p>общий метод обработки файла pid состоит в том, чтобы создать его во время инициализации и удалить его из любого выхода, как обычного, так и обработчика сигнала.</p><p>существует два канонических способа атомарного создания/проверки файла. основным в наши дни является его открытие с флагом <code>o\_excl</code>: если файл уже существует, вызов не выполняется. старый способ (обязательный для систем без <code>o\_excl</code>) заключается в создании его со случайным именем и ссылкой на него. ссылка не удастся, если цель существует.</p>

<p>см. kerrisk's <a href="http://www.man7.org/tlpi/">интерфейс программирования linux</a> , раздел 55.6 <a href="http://www.man7.org/tlpi/code/online/dist/filelock/create\_pid\_file.c.html">"запуск всего одного экземпляра программы"</a> , который основан на реализации pidfile в unix network programming стивенса, v2.</p><p>также обратите внимание, что расположение pid-файла обычно обрабатывается дистрибутивом (с помощью скрипта init), поэтому хорошо написанный демон примет аргумент командной строки для указания pid-файла и не допустит случайного переопределения файла конфигурации. он также должен изящно обрабатывать устаревший файл pid (o\_excl не должен использоваться). следует использовать блокировку файлов fcntl () - вы можете предположить, что pid-файл демона находится в локальной (не nfs) файловой системе.</p>

<p>в зависимости от дистрибутива, это фактически скрипт инициализации, который обрабатывает pid-файл. он проверяет существование при запуске, удаляет при остановке и т.д. мне не нравится делать это таким образом. я пишу свои собственные сценарии инициализации и обычно не использую стандартные функции инициализации.</p><p>хорошо написанная программа (демон) будет иметь какой-то файл конфигурации, в котором будет указано, где должен быть записан этот pid-файл (если есть). он также позаботится о том, чтобы установить обработчики сигналов, чтобы файл pid очищался при нормальном или ненормальном выходе при любой обработке сигнала. затем файл pid дает сценарию инициализации правильный pid, чтобы его можно было остановить.</p><p>поэтому, если pid-файл уже существует при запуске, это очень хороший показатель для программы, что он ранее потерпел крах и должен предпринять какие-то усилия по восстановлению (если применимо). вы как бы стреляете в эту логику, если у вас есть сам скрипт init, проверяющий наличие pid или отменяющий его связь.</p><p>что касается пространства имен, оно должно следовать за именем программы. если вы запускаете 'foo-daemon', это будет foo-daemon.pid</p><p>вам также следует изучить/var/lock/subsys, однако он используется в основном в версиях red hat.</p>

<p>пакет <code>systemd</code> в red hat 7 предоставляет справочную страницу <code>daemon(7)</code> со строкой заголовка «написание и упаковка системных демонов».</p><p>на этой странице руководства обсуждается демонизация «старого стиля» (sysv) и «нового стиля» (systemd). в новом стиле systemd сама обрабатывает pid-файлы для вас (если так настроено). тем не менее, в старом стиле, страница руководства имеет следующее:</p><blockquote> <ol start="12"> <li>в процессе демона напишите pid демона (как возвращено getpid ()) в файл pid, например /run/foobar.pid (для гипотетического демона "foobar"), чтобы гарантировать, что демон не может быть запущен более одного раза . это должно быть реализовано без гонки, чтобы pid-файл был обновляется только тогда, когда проверяется в то же время, что pid ранее сохраненный в файле pid больше не существует или принадлежит чужой процесс.</li> </ol> </blockquote><p>вы также можете прочитать эту справочную страницу <a href="http://0pointer.de/public/systemd-man/daemon.html#sysv%20daemons">онлайн</a> .</p>