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
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
