Hello! On Thu, Nov 23, 2017 at 09:00:07PM +0200, Gena Makhomed wrote:
> On 23.11.2017 19:13, Maxim Dounin wrote: > > >>>> В systemd's daemon(7) manpage очень подробно расписано > >>>> как должны вести себя SysV Daemons при работе с systemd. > >>>> И очевидно, что nginx этим требованиям не соответствует. > > >>>> Original process должен вызывать exit() только после того, > >>>> как будет полностью завершена инициализация daemon process, > >>>> в частности, после того как daemon process создаст свой pid файл. > > >>> Это, что называется, всё очень интересно, но вызывает сомнение > >>> успех подобных рекомендаций. Особенно с учётом отсутствия > >>> каких-либо внятных примеров того, что же использовать вместо > >>> daemon(3). О чём я, собственно, и писал выше. > > >> Что использовать вместо daemon(3) документировано в daemon(7): > >> https://www.freedesktop.org/software/systemd/man/daemon.html > > >> Lennart Poettering очень подробно ответил на этот вопрос в рассылке: > >> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039830.html > > >> Впрочем, если очень хочется использовать все-таки daemon(3) то можно: > >> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039834.html > > >> Кстати, Lennart Poettering нашел еще одну ошибку в исходниках nginx: > >> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039832.html > > > Это всё замечательно (за вычетом того, предлагаемое использование > > daemon(3) почему-то не учитывает, что после вызова daemon(3) > > parent-процесса уже нет, а "ошибка" - не ошибка), но не отменяет > > того, что чуть менее, чем все существующие демоны делают именно > > "daemon(); write_pidfile();", и при таком подходе - ситуацию не > > изменить. > > А при каком подходе ситуацию c nginx изменить можно? > Если говорить конструктивно. Чтобы изменить ситуацию конкретно с nginx - нужно сесть и сделать хороший патч. Очевидно, это сделать можно, и даже не очень сложно. Я, как уже неоднократно сказал, не возражаю. Но сама идея, что все должны сесть и заняться выпиливанием стандартного паттерна, который работал десятки лет, и делать вместо это что-то своё с синхронизацией - не взлетит. > Посмотрел у себя в системе, CentOS 7.4 - там достаточно мало осталось > сервисов Type=forking. Postfix например, запускает много процессов, > как и nginx - проверил его исходники, он действует точно так, > как рекомендуется в документе systemd's daemon(7) manpage. > > О каких именно "чуть менее, чем все существующие демоны" > сервисах Вы говорите? Есть еще кроме nginx примеры некорректного > поведения systemd-сервисов с Type=forking которые запускают много > дочерних процессов как это делает nginx или postfix? Не вижу причин, почему демоны с "много дочерних процессов" должны отличаться от сервисов с "мало дочерних процессов". In no particular order, - memcached, делает deamonize() (который суть daemon(3) и завершает исходный процесс), после чего пишет pid-файл. https://github.com/memcached/memcached/blob/master/memcached.c#L6788 https://github.com/memcached/memcached/blob/master/memcached.c#L6924 - httpd, делает apr_proc_detach() (который суть daemon(3) и тоже завершает исходный процесс) в worker_pre_config(), и сильно после пишет pid-файл (в worker_run()). https://github.com/apache/httpd/blob/trunk/server/mpm/worker/worker.c#L2002 https://github.com/apache/httpd/blob/trunk/server/mpm/worker/worker.c#L1663 - Reference-реализация PEP 3143 - Standard daemon process library, https://www.python.org/dev/peps/pep-3143/, зовётся функция detach_process_context() (которая в свою очередь зовёт функцию с говорящим названием fork_then_exit_parent()), потом пишется pid-файл. https://pagure.io/python-daemon/blob/master/f/daemon/daemon.py#_376 https://pagure.io/python-daemon/blob/master/f/daemon/daemon.py#_389 - nptd, в отсутствии опции --wait-sync (которая суть замена ntpdate) выходит сразу после fork(), pid-файл пишется позже в рамках getconfig(). https://github.com/ntp-project/ntp/blob/stable/ntpd/ntpd.c#L730 https://github.com/ntp-project/ntp/blob/stable/ntpd/ntpd.c#L892 Тысячи их. [...] -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx-ru mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-ru
