Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-25 Пенетрантность Slawa Olhovchenkov 
On Sat, Nov 25, 2017 at 04:21:44PM +0200, Gena Makhomed wrote:

> On 24.11.2017 21:43, Maxim Dounin wrote:
> 
> >>>>> Давайте, всё-таки, опеределимся: мы за всё хорошее против всего
> >>>>> плохого (== чтобы демоны писали pid-файлы до выхода запущенного
> >>>>> процесса, потому что по другому - плохо), или вопрос исключительно
> >>>>> в том, чтобы systemd не ругался в логи?
> 
> >>>> Так ведь systemd и ругается в логи потому что по другому - плохо.
> >>>> Например, команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop"
> >>>> будет глючить на системах, где nginx запускается в виде SysV сервиса.
> 
> >>> То есть боремся за всё хорошее против всего плохого, правильно я
> >>> понял ответ?
> 
> >> Есть спецификация на запуск сервисов под управлением systemd.
> >> Вопрос лишь в том, соответствует nginx этой спецификации или нет.
> 
> > Нет.  Вопрос в том, соответствует ли эта "спецификация",
> > придуманная авторами systemd, тому, как пишутся и работают демоны
> > последние 25+ лет.  И ответ - не соответствует.
> 
> А как быть с тем, что гугл выдает примерно 51500 страниц,
> если в строке поиска задать:
> 
> systemd: PID file /var/run/nginx.pid not readable (yet?) after start.
> 
> ?
> 
> Ведь это всё отрицательным образом сказывается на имидже nginx.

я уже не первый раз читаю про имидж nginx и отрицательный
образ. и как-то не могу никак понять о чем речь-то?

обычно для того, что бы имидж программы не портился его принято класть
на нормальные, не помойные hdd/sdd, ну или если уж брать помойные
носители, то собирать их в RAID (I -- Inexpensive). причем тут
systemd? или поттеринг теперь занялся еще и тем, что стал портить
имиджи програм? (это конечно странно, но с него станется). ну значит
надо поставить флаг immutable на имидж. шоб неповадно было.

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-25 Пенетрантность Gena Makhomed 

On 24.11.2017 21:43, Maxim Dounin wrote:


Давайте, всё-таки, опеределимся: мы за всё хорошее против всего
плохого (== чтобы демоны писали pid-файлы до выхода запущенного
процесса, потому что по другому - плохо), или вопрос исключительно
в том, чтобы systemd не ругался в логи?



Так ведь systemd и ругается в логи потому что по другому - плохо.
Например, команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop"
будет глючить на системах, где nginx запускается в виде SysV сервиса.



То есть боремся за всё хорошее против всего плохого, правильно я
понял ответ?



Есть спецификация на запуск сервисов под управлением systemd.
Вопрос лишь в том, соответствует nginx этой спецификации или нет.



Нет.  Вопрос в том, соответствует ли эта "спецификация",
придуманная авторами systemd, тому, как пишутся и работают демоны
последние 25+ лет.  И ответ - не соответствует.


А как быть с тем, что гугл выдает примерно 51500 страниц,
если в строке поиска задать:

systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

?

Ведь это всё отрицательным образом сказывается на имидже nginx.

Можно ли пойти по второму пути и сделать в nginx workaround,
чтобы systemd не ругался в логи?

Например, в функции ngx_daemon() перед вызовом exit(0)
добавить ngx_msleep(100) ? Этого вполне должно хватить.

--
Best regards,
 Gena

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-24 Пенетрантность Maxim Dounin 
Hello!

On Fri, Nov 24, 2017 at 04:48:41PM +0200, Gena Makhomed wrote:

> On 24.11.2017 15:33, Maxim Dounin wrote:
> 
> >>> Давайте, всё-таки, опеределимся: мы за всё хорошее против всего
> >>> плохого (== чтобы демоны писали pid-файлы до выхода запущенного
> >>> процесса, потому что по другому - плохо), или вопрос исключительно
> >>> в том, чтобы systemd не ругался в логи?
> 
> >> Так ведь systemd и ругается в логи потому что по другому - плохо.
> >> Например, команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop"
> >> будет глючить на системах, где nginx запускается в виде SysV сервиса.
> 
> > То есть боремся за всё хорошее против всего плохого, правильно я
> > понял ответ?
> 
> Есть спецификация на запуск сервисов под управлением systemd.
> Вопрос лишь в том, соответствует nginx этой спецификации или нет.

Нет.  Вопрос в том, соответствует ли эта "спецификация", 
придуманная авторами systemd, тому, как пишутся и работают демоны 
последние 25+ лет.  И ответ - не соответствует.

-- От, из-звольте. Уся рота, ч-черт бы ее побрал, идет не в ногу. 
Один п-подпоручик идет в ногу.

[...]

> В TODO файле systemd есть такая запись: "- introduce Type=pid-file"
> Это как раз и есть это предложение, просто оно еще не реализовано.

Вот и замечательно.  Как доделают - проблема с сообщением решится 
сама собой.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-24 Пенетрантность Vadim A. Misbakh-Soloviov 
В письме от пятница, 24 ноября 2017 г. 17:48:41 MSK пользователь Gena Makhomed 
написал:
> nginx ведь соответствует например, спецификации на протокол HTTP,

Например, потому что NginX — HTTP-сервер,

> почему же он не может соответствовать спецификации из daemon(7)?

а SystemD при этом — лишь **одна** из **множества** существующих init-систем 
на **одной** из **множества** операционных систем, на которых работает NginX.

А ещё, потому что NginX соответствует спецификации daemon(3). Которая, в 
отличие от daemon(7), является релевантной для всех ОС (включая в т.ч. Linux) 
на которых существует соответствующая man-страница.

В то время, как спецификация daemon(7) является релевантной только для systemd 
и существует только на системах с установленных systemd (потому что сама man-
страница является частью systemd).

Самим разработчикам NginX не интересно в работающий десятилетиями на множестве 
ОС воркфлоу вставлять пучок костылей для соответствия требованиям одного-
единственного сервис-менеджера из множества. К тому же, особенно мило 
требование по их вставке выглядит в свете того, что за всё время существования 
SystemD его авторы до сих пор не хотят сделать возможность хендлить рестарт (а 
не просто stop+start), о которой говорилось в соседнем треде созданном вами.

Т.е. картина такая: разработчики SystemD требуют чтобы под них подстраивались 
другие, при этом сами ни под чей воркфлоу подстроиться не хотят. Даже не 
смотря на его повсеместное (кроме systemd) существование десятилетиями.



В связи с этим, как вам уже сказали: если **вам** это нужно — сделайте патч 
или наймите того, кто его сделает.

И не просто патч, а соответствующий код-стайлу NginX и вставляющий как можно 
меньше костылей.
И, крайне желательно, с вынесением всего этого в `--with-systemd`/`#ifdef 
WITH_SYSTEMD` (или типа того).

Иначе весь этот тред — переливание из пустого в порожнее, т.к. разработчикам 
NginX нет ни интереса, ни стимула на ровном месте заниматься подобными 
непотребствами.



И, к слову, как я говорил выше, на том же OpenRC (который, так-то, надстройка 
над SysV-init) подобных проблем  с NginX не наблюдается. Интересно, почему бы 
это?..

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-24 Пенетрантность Gena Makhomed 

On 24.11.2017 15:33, Maxim Dounin wrote:


Давайте, всё-таки, опеределимся: мы за всё хорошее против всего
плохого (== чтобы демоны писали pid-файлы до выхода запущенного
процесса, потому что по другому - плохо), или вопрос исключительно
в том, чтобы systemd не ругался в логи?



Так ведь systemd и ругается в логи потому что по другому - плохо.
Например, команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop"
будет глючить на системах, где nginx запускается в виде SysV сервиса.



То есть боремся за всё хорошее против всего плохого, правильно я
понял ответ?


Есть спецификация на запуск сервисов под управлением systemd.
Вопрос лишь в том, соответствует nginx этой спецификации или нет.

nginx ведь соответствует например, спецификации на протокол HTTP,
почему же он не может соответствовать спецификации из daemon(7)?

Это создает проблемы при использовании legacy систем инициализации?
Нет, наборот, решает имеющиеся проблемы с race conditions при старте.

Не понимаю в чем тут проблема, если поддержка этой спецификации
требует добавления в nginx всего нескольких десятков строк кода.


Ну вот тогда, как я уже неоднократно говорил - выбранная методика
борьбы - не работает и не будет работать.  И поведение nginx'а тут
совершенно нерелевантно.


Это не вопрос борьбы, это вопрос соответствия требованиям спецификации.

Если в unit-файле nginx написано Type=forking - ожидается что nginx
будет вести себя так, как того требует спецификация сервисов systemd.

По поводу предложения "Проще всего, IMHO, это было бы заткнуть
на уровне systemd, дожидаясь появления pid-файла при необходимости"

В TODO файле systemd есть такая запись: "- introduce Type=pid-file"
Это как раз и есть это предложение, просто оно еще не реализовано.


Отдельно отмечу, что смысла в этой борьбе - приблизительно столько
же, сколько смысла в команде "/etc/init.d/nginx start ;
/etc/init.d/nginx stop".


Есть различные баги в софте, в частности - race conditions,
Команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop"
- это просто пример, как можно этот баг воспроизвести.

--
Best regards,
 Gena

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-24 Пенетрантность Maxim Dounin 
Hello!

On Fri, Nov 24, 2017 at 01:30:41PM +0200, Gena Makhomed wrote:

> On 24.11.2017 6:12, Maxim Dounin wrote:
> 
> >>> Но сама идея, что все должны сесть и заняться выпиливанием
> >>> стандартного паттерна, который работал десятки лет, и делать
> >>> вместо это что-то своё с синхронизацией - не взлетит.
> 
> >> Эта идея уже взлетела. Если демон состоит из одного процесса
> >> - systemd может однозначно узнать его pid, проблемы могут возникать
> >> только с теми демонами, которые состоят из нескольких процессов.
> >> Из известных мне сервисов состоящих из более чем одного процесса:
> 
> >> * postfix - сделали синхронизацию и проблем с systemd больше нет.
> >> * httpd - перевели на Type=notify и проблем с systemd больше нет.
> >> * php-fpm - перевели на Type=notify и проблем с systemd больше нет.
> >> * nginx - только с этим сервисом наблюдаются проблемы под systemd.
> 
> > Давайте, всё-таки, опеределимся: мы за всё хорошее против всего
> > плохого (== чтобы демоны писали pid-файлы до выхода запущенного
> > процесса, потому что по другому - плохо), или вопрос исключительно
> > в том, чтобы systemd не ругался в логи?
> 
> Так ведь systemd и ругается в логи потому что по другому - плохо.
> Например, команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop"
> будет глючить на системах, где nginx запускается в виде SysV сервиса.

То есть боремся за всё хорошее против всего плохого, правильно я 
понял ответ?

Ну вот тогда, как я уже неоднократно говорил - выбранная методика 
борьбы - не работает и не будет работать.  И поведение nginx'а тут 
совершенно нерелевантно.

Отдельно отмечу, что смысла в этой борьбе - приблизительно столько 
же, сколько смысла в команде "/etc/init.d/nginx start ; 
/etc/init.d/nginx stop".

[...]

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-24 Пенетрантность Maxim Dounin 
Hello!

On Fri, Nov 24, 2017 at 12:16:08PM +0300, Vadim A. Misbakh-Soloviov wrote:

> Прошу прощения за то, что вставляю свои пять копеек, но у меня, почему-то, на 
> Gentoo NgX вполне замечательно стартует на SystemD без ругани, на которую 
> жалуется ОП:

[...]

> В связи с этим у меня возникает вопрос: а что я, собственно, делаю не так?

Там race:

- запущенный процесс делает fork() и выходит;

- потомок делает setsid(), umask(), перенаправляет stdin/stdout в 
  /dev/null, и уже после этого создаёт pid-файл.

Соответственно systemd может успеть попытаться прочитать pid-файл 
до того, как он создан.  Успеет или нет - зависит от количества 
процессоров и поведения шедулера.

У меня получается воспроизвести проблему на виртуалке с Ubuntu 
после того, как я оставил в ней только один процессор.  Где-то раз 
в 3-5 запусков он успевает.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-24 Пенетрантность Pavel V. 
Здравствуйте!

> Например, команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop"
> будет глючить на системах, где nginx запускается в виде SysV сервиса.

Никогда не возникало желания выполнить команду

"/etc/init.d/nginx start ; /etc/init.d/nginx stop"

Что я делаю не так, или чего не делаю?


> - Доктор, когда я вот-вот-так делаю - у меня болит! :((
> - А вы вот-вот-так - не делайте. :-|



-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-24 Пенетрантность Konstantin Tokarev 


24.11.2017, 14:30, "Gena Makhomed" :
> On 24.11.2017 6:12, Maxim Dounin wrote:
>
  Но сама идея, что все должны сесть и заняться выпиливанием
  стандартного паттерна, который работал десятки лет, и делать
  вместо это что-то своё с синхронизацией - не взлетит.
>
>>>  Эта идея уже взлетела. Если демон состоит из одного процесса
>>>  - systemd может однозначно узнать его pid, проблемы могут возникать
>>>  только с теми демонами, которые состоят из нескольких процессов.
>>>  Из известных мне сервисов состоящих из более чем одного процесса:
>
>>>  * postfix - сделали синхронизацию и проблем с systemd больше нет.
>>>  * httpd - перевели на Type=notify и проблем с systemd больше нет.
>>>  * php-fpm - перевели на Type=notify и проблем с systemd больше нет.
>>>  * nginx - только с этим сервисом наблюдаются проблемы под systemd.
>
>>  Давайте, всё-таки, опеределимся: мы за всё хорошее против всего
>>  плохого (== чтобы демоны писали pid-файлы до выхода запущенного
>>  процесса, потому что по другому - плохо), или вопрос исключительно
>>  в том, чтобы systemd не ругался в логи?
>
> Так ведь systemd и ругается в логи потому что по другому - плохо.
> Например, команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop"
> будет глючить на системах, где nginx запускается в виде SysV сервиса.
>
>>  Если за всё хорошее - то проблема, очевидно, не ограничевается
>>  сервисами из более чем одного процесса, и не решается переводом на
>>  Type=notify. Она вообще ортогональна существованию systemd. И
>>  идея её решения, очевидно, не взлетела, и уже наверное не взлетит.
>
> В MacOS X есть launchd - там сервисам вообще запрещено делать fork()
> и вызывать функцию daemon() - и ничего, никто еще умер, все работает.
> https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html

В daemontools, runit и т.п., которые появились еще раньше, fork тоже не 
поощряется

>
> systemd - это такой же launchd, но для системы Linux. Только для своих
> конфигурационных файлов он использует ini синтаксис вместо формата xml
> и небезуспешно пытается быть обратно совместимым со старыми SysV Daemons
>
> Но свои специфичные требования к сервисам есть и у systemd:
> https://www.freedesktop.org/software/systemd/man/daemon.html
>
> 15. Call exit() in the original process. The process that invoked
> the daemon must be able to rely on that this exit() happens
> after initialization is complete and all external communication
> channels are established and accessible.
>
> Одним из таких communication channels как раз и является pid-файл.
>
>>  Если чтобы systemd не ругался - то проблема, очевидно, не в том,
>>  чтобы сделать хорошо, а в том, убрать конкретную ругань (которая
>>  не несёт практического смысла, см. ниже). И предолженный ранее
>>  workaround про sleep 0.1 - вполне себе в этом ключе же решение?
>
> sleep 0.1 - это race condition на ровном месте, плохой workaround.
> Лучше будет если такого workaround`а в unit-файлах nginx не делать.
>
> Когда команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop"
> глючит - это ведь отрицательно сказывается на репутации nginx.
> И эта проблема вообще ортогональна существованию systemd.
>
>>>  systemd однозначно определяет pid демонов состоящих из одного процесса
>>>  и поэтому для них в юнит-файле можно вообще не указывать опцию PIDFile=
>>>  - все будет работать как надо даже если они стартуют без синхронизации.
>>>
>>>  Вот что говорит Lennart Poettering из Red Hat:
>>>
>>>  If you use Type=forking, then you'll get away with not specifiying a
>>>  PID file in most cases, but it's racy as soon as you have more than
>>>  one daemon process, and nginx appears to be one of this kind, hence
>>>  please specify PIDFile=.
>>>
>>>  
>>> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039833.html
>>
>>  Ну вот я посмотрел на это место чуть подробнее, и имею сказать,
>>  что это не совсем соответствует действительности. Единственное,
>>  для чего нужен PIDFile в случае nginx'а - это чтобы systemd
>>  нормально реагировал на binary upgrade.
>>
>>  Для правильного детектирования основного процесса при запуске
>>  PIDFile не нужен, так как master-процесс - единственный, у кого
>>  parent'ом systemd, у остальных процессов parent'ом будет master.
>>  И соответственно все остальные процессы успешно отфильтрует вот
>>  этот код,
>>  https://github.com/systemd/systemd/blob/master/src/core/cgroup.c#L1727:
>>
>>   /* Ignore processes that aren't our kids */
>>   if (get_process_ppid(npid, ) >= 0 && ppid != mypid)
>>   continue;
>>
>>  Однако если PIDFile не указывать, то "service nginx upgrade"
>>  приведёт к тому, что после выхода старого мастера systemd будет
>>  считать, что nginx умер, и убьёт все новые процессы. Поэтому
>>  PIDFile указывать таки надо.
>>
>>  Соответственно имеем то что имеем: PIDFile указывать надо, от
>>  этого на старте могут появляться

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-24 Пенетрантность Vadim A. Misbakh-Soloviov 
В письме от пятница, 24 ноября 2017 г. 14:30:41 MSK пользователь Gena Makhomed 
написал:
> Когда команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop"
> глючит

Опять же, данная команда на gentoo (на инстансах без systemd) у меня тоже не 
глючит. При любом количестве воркеров.

И у меня всё тот же вопрос: что же я делаю не так и как мне воспроизвести вашу 
проблему?

// просто мимокрокодил
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-24 Пенетрантность Gena Makhomed 

On 24.11.2017 6:12, Maxim Dounin wrote:


Но сама идея, что все должны сесть и заняться выпиливанием
стандартного паттерна, который работал десятки лет, и делать
вместо это что-то своё с синхронизацией - не взлетит.



Эта идея уже взлетела. Если демон состоит из одного процесса
- systemd может однозначно узнать его pid, проблемы могут возникать
только с теми демонами, которые состоят из нескольких процессов.
Из известных мне сервисов состоящих из более чем одного процесса:



* postfix - сделали синхронизацию и проблем с systemd больше нет.
* httpd - перевели на Type=notify и проблем с systemd больше нет.
* php-fpm - перевели на Type=notify и проблем с systemd больше нет.
* nginx - только с этим сервисом наблюдаются проблемы под systemd.



Давайте, всё-таки, опеределимся: мы за всё хорошее против всего
плохого (== чтобы демоны писали pid-файлы до выхода запущенного
процесса, потому что по другому - плохо), или вопрос исключительно
в том, чтобы systemd не ругался в логи?


Так ведь systemd и ругается в логи потому что по другому - плохо.
Например, команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop"
будет глючить на системах, где nginx запускается в виде SysV сервиса.


Если за всё хорошее - то проблема, очевидно, не ограничевается
сервисами из более чем одного процесса, и не решается переводом на
Type=notify.  Она вообще ортогональна существованию systemd.  И
идея её решения, очевидно, не взлетела, и уже наверное не взлетит.


В MacOS X есть launchd - там сервисам вообще запрещено делать fork()
и вызывать функцию daemon() - и ничего, никто еще умер, все работает.
https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html

systemd - это такой же launchd, но для системы Linux. Только для своих
конфигурационных файлов он использует ini синтаксис вместо формата xml
и небезуспешно пытается быть обратно совместимым со старыми SysV Daemons

Но свои специфичные требования к сервисам есть и у systemd:
https://www.freedesktop.org/software/systemd/man/daemon.html

15. Call exit() in the original process. The process that invoked
the daemon must be able to rely on that this exit() happens
after initialization is complete and all external communication
channels are established and accessible.

Одним из таких communication channels как раз и является pid-файл.


Если чтобы systemd не ругался - то проблема, очевидно, не в том,
чтобы сделать хорошо, а в том, убрать конкретную ругань (которая
не несёт практического смысла, см. ниже).  И предолженный ранее
workaround про sleep 0.1 - вполне себе в этом ключе же решение?


sleep 0.1 - это race condition на ровном месте, плохой workaround.
Лучше будет если такого workaround`а в unit-файлах nginx не делать.

Когда команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop"
глючит - это ведь отрицательно сказывается на репутации nginx.
И эта проблема вообще ортогональна существованию systemd.


systemd однозначно определяет pid демонов состоящих из одного процесса
и поэтому для них в юнит-файле можно вообще не указывать опцию PIDFile=
- все будет работать как надо даже если они стартуют без синхронизации.

Вот что говорит Lennart Poettering из Red Hat:

If you use Type=forking, then you'll get away with not specifiying a
PID file in most cases, but it's racy as soon as you have more than
one daemon process, and nginx appears to be one of this kind, hence
please specify PIDFile=.

https://lists.freedesktop.org/archives/systemd-devel/2017-November/039833.html


Ну вот я посмотрел на это место чуть подробнее, и имею сказать,
что это не совсем соответствует действительности.  Единственное,
для чего нужен PIDFile в случае nginx'а - это чтобы systemd
нормально реагировал на binary upgrade.

Для правильного детектирования основного процесса при запуске
PIDFile не нужен, так как master-процесс - единственный, у кого
parent'ом systemd, у остальных процессов parent'ом будет master.
И соответственно все остальные процессы успешно отфильтрует вот
этот код,
https://github.com/systemd/systemd/blob/master/src/core/cgroup.c#L1727:

 /* Ignore processes that aren't our kids */
 if (get_process_ppid(npid, ) >= 0 && ppid != mypid)
 continue;

Однако если PIDFile не указывать, то "service nginx upgrade"
приведёт к тому, что после выхода старого мастера systemd будет
считать, что nginx умер, и убьёт все новые процессы.  Поэтому
PIDFile указывать таки надо.

Соответственно имеем то что имеем: PIDFile указывать надо, от
этого на старте могут появляться сообщения про "PID file not ... yet?".
Сообщения эти безвредные, и ни на что не влияют, кроме собственно
появления самих сообщений.

Если идти по пути синхронизации через pipe, то патч получается
как-то такой.  Не могу сказать, что он мне нравится, особенно в
контексте решения задачи "чтобы у systemd в логе стало на одну
строчку меньше".


Есть проблема "/etc/init.d/nginx start ; /etc/init.d/nginx stop"
на старых системах,

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-24 Пенетрантность Vadim A. Misbakh-Soloviov 
Прошу прощения за то, что вставляю свои пять копеек, но у меня, почему-то, на 
Gentoo NgX вполне замечательно стартует на SystemD без ругани, на которую 
жалуется ОП:

```
ноя 24 12:12:24 note systemd[1]: Starting The nginx HTTP and reverse proxy 
server...
ноя 24 12:12:25 note nginx[17684]: nginx: the configuration file /etc/nginx/
nginx.conf syntax is ok
ноя 24 12:12:25 note nginx[17684]: nginx: configuration file /etc/nginx/
nginx.conf test is successful
ноя 24 12:12:25 note systemd[1]: Started The nginx HTTP and reverse proxy 
server.
```

Код nginx.service при этом такой:
```
[Unit]
Description=The nginx HTTP and reverse proxy server
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/bin/kill -HUP $MAINPID
ExecStop=/bin/kill -QUIT $MAINPID

[Install]
WantedBy=multi-user.target
```

В связи с этим у меня возникает вопрос: а что я, собственно, делаю не так?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-24 Пенетрантность Evgeniy Berdnikov 
On Fri, Nov 24, 2017 at 07:12:31AM +0300, Maxim Dounin wrote:
> +if (read(pp[0], buf, 1) != 1) {
> +ngx_log_error(NGX_LOG_EMERG, log, ngx_errno, "read() pipe 
> failed");
> +return NGX_ERROR;
> +}
> +
> +if (close(pp[0]) == -1) {
> +ngx_log_error(NGX_LOG_EMERG, log, ngx_errno, "close() failed");

 "close() pipe failed"

> +return NGX_ERROR;
> +}
> +
>  exit(0);
>  }
>  
> @@ -68,3 +98,26 @@
>  
>  return NGX_OK;
>  }
> +
> +
> +ngx_int_t
> +ngx_daemon_sync(ngx_log_t *log)
> +{
> +if (ngx_daemon_fd == NGX_INVALID_FILE) {
> +return NGX_OK;
> +}
> +
> +if (write(ngx_daemon_fd, "", 1) != 1) {
> +ngx_log_error(NGX_LOG_EMERG, log, ngx_errno, "write() failed");

 "write() pipe failed"

> +return NGX_ERROR;
> +}
> +
> +if (close(ngx_daemon_fd) == -1) {
> +ngx_log_error(NGX_LOG_EMERG, log, ngx_errno, "close() failed");

 "close() pipe failed"

> +return NGX_ERROR;

 Можно ещё заменить "pp" на "sync_fd" / "sync_pipe".
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-23 Пенетрантность Maxim Dounin 
Hello!

On Fri, Nov 24, 2017 at 01:12:46AM +0200, Gena Makhomed wrote:

> On 23.11.2017 23:00, Maxim Dounin wrote:
> 
> >>> Это всё замечательно (за вычетом того, предлагаемое использование
> >>> daemon(3) почему-то не учитывает, что после вызова daemon(3)
> >>> parent-процесса уже нет, а "ошибка" - не ошибка), но не отменяет
> >>> того, что чуть менее, чем все существующие демоны делают именно
> >>> "daemon(); write_pidfile();", и при таком подходе - ситуацию не
> >>> изменить.
> 
> >> А при каком подходе ситуацию c nginx изменить можно?
> >> Если говорить конструктивно.
> 
> > Чтобы изменить ситуацию конкретно с nginx - нужно сесть и сделать
> > хороший патч.  Очевидно, это сделать можно, и даже не очень
> > сложно.  Я, как уже неоднократно сказал, не возражаю.
> 
> Для меня это будет слишком сложный патч, в разумные сроки не напишу.
> 
> > Но сама идея, что все должны сесть и заняться выпиливанием
> > стандартного паттерна, который работал десятки лет, и делать
> > вместо это что-то своё с синхронизацией - не взлетит.
> 
> Эта идея уже взлетела. Если демон состоит из одного процесса
> - systemd может однозначно узнать его pid, проблемы могут возникать
> только с теми демонами, которые состоят из нескольких процессов.
> Из известных мне сервисов состоящих из более чем одного процесса:
> 
> * postfix - сделали синхронизацию и проблем с systemd больше нет.
> * httpd - перевели на Type=notify и проблем с systemd больше нет.
> * php-fpm - перевели на Type=notify и проблем с systemd больше нет.
> * nginx - только с этим сервисом наблюдаются проблемы под systemd.

Давайте, всё-таки, опеределимся: мы за всё хорошее против всего 
плохого (== чтобы демоны писали pid-файлы до выхода запущенного 
процесса, потому что по другому - плохо), или вопрос исключительно 
в том, чтобы systemd не ругался в логи?

Если за всё хорошее - то проблема, очевидно, не ограничевается 
сервисами из более чем одного процесса, и не решается переводом на 
Type=notify.  Она вообще ортогональна существованию systemd.  И 
идея её решения, очевидно, не взлетела, и уже наверное не взлетит.

Если чтобы systemd не ругался - то проблема, очевидно, не в том, 
чтобы сделать хорошо, а в том, убрать конкретную ругань (которая 
не несёт практического смысла, см. ниже).  И предолженный ранее 
workaround про sleep 0.1 - вполне себе в этом ключе же решение?

> >> О каких именно "чуть менее, чем все существующие демоны"
> >> сервисах Вы говорите? Есть еще кроме nginx примеры некорректного
> >> поведения systemd-сервисов с Type=forking которые запускают много
> >> дочерних процессов как это делает nginx или postfix?
> 
> > Не вижу причин, почему демоны с "много дочерних процессов" должны
> > отличаться от сервисов с "мало дочерних процессов".
> 
> systemd однозначно определяет pid демонов состоящих из одного процесса
> и поэтому для них в юнит-файле можно вообще не указывать опцию PIDFile=
> - все будет работать как надо даже если они стартуют без синхронизации.
> 
> Вот что говорит Lennart Poettering из Red Hat:
> 
> If you use Type=forking, then you'll get away with not specifiying a
> PID file in most cases, but it's racy as soon as you have more than
> one daemon process, and nginx appears to be one of this kind, hence
> please specify PIDFile=.
> 
> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039833.html

Ну вот я посмотрел на это место чуть подробнее, и имею сказать, 
что это не совсем соответствует действительности.  Единственное, 
для чего нужен PIDFile в случае nginx'а - это чтобы systemd 
нормально реагировал на binary upgrade.

Для правильного детектирования основного процесса при запуске 
PIDFile не нужен, так как master-процесс - единственный, у кого 
parent'ом systemd, у остальных процессов parent'ом будет master.  
И соответственно все остальные процессы успешно отфильтрует вот 
этот код,
https://github.com/systemd/systemd/blob/master/src/core/cgroup.c#L1727:

/* Ignore processes that aren't our kids */
if (get_process_ppid(npid, ) >= 0 && ppid != mypid)
continue;

Однако если PIDFile не указывать, то "service nginx upgrade" 
приведёт к тому, что после выхода старого мастера systemd будет 
считать, что nginx умер, и убьёт все новые процессы.  Поэтому 
PIDFile указывать таки надо.

Соответственно имеем то что имеем: PIDFile указывать надо, от 
этого на старте могут появляться сообщения про "PID file not ... yet?".  
Сообщения эти безвредные, и ни на что не влияют, кроме собственно 
появления самих сообщений.

Если идти по пути синхронизации через pipe, то патч получается 
как-то такой.  Не могу сказать, что он мне нравится, особенно в 
контексте решения задачи "чтобы у systemd в логе стало на одну 
строчку меньше".

diff -r 325b3042edd6 src/core/nginx.c
--- a/src/core/nginx.c  Thu Nov 23 16:33:40 2017 +0300
+++ b/src/core/nginx.c  Fri Nov 24 07:07:44 2017 +0300
@@ -361,6 +361,10 @@
 return 1;
 }
 
+if (ngx_daemon_sync(cycle->log) != NGX_OK) {
+

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-23 Пенетрантность Gena Makhomed 

On 23.11.2017 23:00, Maxim Dounin wrote:


Это всё замечательно (за вычетом того, предлагаемое использование
daemon(3) почему-то не учитывает, что после вызова daemon(3)
parent-процесса уже нет, а "ошибка" - не ошибка), но не отменяет
того, что чуть менее, чем все существующие демоны делают именно
"daemon(); write_pidfile();", и при таком подходе - ситуацию не
изменить.



А при каком подходе ситуацию c nginx изменить можно?
Если говорить конструктивно.



Чтобы изменить ситуацию конкретно с nginx - нужно сесть и сделать
хороший патч.  Очевидно, это сделать можно, и даже не очень
сложно.  Я, как уже неоднократно сказал, не возражаю.


Для меня это будет слишком сложный патч, в разумные сроки не напишу.


Но сама идея, что все должны сесть и заняться выпиливанием
стандартного паттерна, который работал десятки лет, и делать
вместо это что-то своё с синхронизацией - не взлетит.


Эта идея уже взлетела. Если демон состоит из одного процесса
- systemd может однозначно узнать его pid, проблемы могут возникать
только с теми демонами, которые состоят из нескольких процессов.
Из известных мне сервисов состоящих из более чем одного процесса:

* postfix - сделали синхронизацию и проблем с systemd больше нет.
* httpd - перевели на Type=notify и проблем с systemd больше нет.
* php-fpm - перевели на Type=notify и проблем с systemd больше нет.
* nginx - только с этим сервисом наблюдаются проблемы под systemd.


О каких именно "чуть менее, чем все существующие демоны"
сервисах Вы говорите? Есть еще кроме nginx примеры некорректного
поведения systemd-сервисов с Type=forking которые запускают много
дочерних процессов как это делает nginx или postfix?



Не вижу причин, почему демоны с "много дочерних процессов" должны
отличаться от сервисов с "мало дочерних процессов".


systemd однозначно определяет pid демонов состоящих из одного процесса
и поэтому для них в юнит-файле можно вообще не указывать опцию PIDFile=
- все будет работать как надо даже если они стартуют без синхронизации.

Вот что говорит Lennart Poettering из Red Hat:

If you use Type=forking, then you'll get away with not specifiying a
PID file in most cases, but it's racy as soon as you have more than
one daemon process, and nginx appears to be one of this kind, hence
please specify PIDFile=.

https://lists.freedesktop.org/archives/systemd-devel/2017-November/039833.html

--
Best regards,
 Gena

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-23 Пенетрантность Maxim Dounin 
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

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-23 Пенетрантность Konstantin Pavlov 
Здравствуйте, Илья,

On 23/11/2017 21:30, Илья Шипицин wrote:
> не совсем про systemd, скорее про пакеты
> 
> не пробовали вот такие хуки 
> https://fedoraproject.org/wiki/Packaging:Scriptlets#Systemd ?
> (для pre, post скриптов)

Мы собираем пакеты не только под systemd-enabled дистрибутивы из одних и тех же 
исходных пакетов, поэтому использовали уже раскрытые версии в соответствущих 
местах (см. http://hg.nginx.org/pkg-oss/file/tip/rpm/SPECS/nginx.spec.in#l238).

-- 
Konstantin Pavlov
www.nginx.com
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-23 Пенетрантность Evgeniy Berdnikov 
On Wed, Nov 22, 2017 at 08:43:14PM +0300, Maxim Dounin wrote:
> С точки зрения практики - паттерн "daemon(); write_pidfile();" 
> используется чуть менее, чем везде, вплоть до соответствующих 
> библиотечных функций.  Так что инициатива выглядит, скажем так, 
> сомнительной.

 Отговорка, скажем так, неубедительная. Есть масса рискованных
 и ненадёжных паттернов поведения, но зачем им следовать, если
 можно сделать всё правильно, и это достаточно просто?
 Например, возможен такой вариант:

 1. Папа выполняет pipe(2) и форкает дочку.
 
 2. Дочка читает конфиги, открывает сокеты и делает все нужные
предварительные проверки, если всё ок -- пишет в пайп
свой pid и закрывает пайп, если нет -- делает exit().

 3. Прочитав пайп, папа видит смотрит, вернулся ли pid или
eof/ошибка. Если прочитан правильный pid, то он записывается
в файл, и папа делает exit(0), если нет, то дочка подбирается
waitpid()ом и её статус выбрасывается через exit() наверх.

 В идеале можно (и я бы сказал нужно) перед чтением пайпа поставить
 на него select() с таймером, чтобы задать максимальное время
 на запуск подпроцесса.

> Проще всего, IMHO, это было бы заткнуть на уровне systemd, 
> дожидаясь появления pid-файла при необходимости.

 Лучше делать не "как проще", а правильно.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-23 Пенетрантность Gena Makhomed 

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 изменить можно?
Если говорить конструктивно.

Посмотрел у себя в системе, CentOS 7.4 - там достаточно мало осталось
сервисов Type=forking. Postfix например, запускает много процессов,
как и nginx - проверил его исходники, он действует точно так,
как рекомендуется в документе systemd's daemon(7) manpage.

О каких именно "чуть менее, чем все существующие демоны"
сервисах Вы говорите? Есть еще кроме nginx примеры некорректного
поведения systemd-сервисов с Type=forking которые запускают много
дочерних процессов как это делает nginx или postfix?

Проблемы в работе под управлением systemd сейчас есть только у nginx:
systemd: PID file /var/run/nginx.pid not readable (yet?) after start.
Все остальные сервисы у меня на серверах под systemd работают нормально.

Когда я спросил у Lennart Poettering насчет того,
что все существующие демоны так делают он мне ответил
"the better written ones synchronize properly".

Хочется чтобы и nginx тоже попадал в эту категорию "better written".

Когда я спрашивал разработчиков systemd чтобы они исправили
systemd, вот что Lennart Poettering из Red Hat мне ответил:

https://lists.freedesktop.org/archives/systemd-devel/2017-November/039834.html

[...]

>>> But "daemon(); write_pidfile();" is common pattern
>>> used by many services and even in library functions.

>> It may be common, but not necessarily correct. The parent process should
>> only exit *after* finishing all the preparations (i.e. something like
>> "fork(); write_pidfile(); exit()"), since systemd uses the exit as a 
signal

>> that the daemon is now "ready".

> You are joking? Why you think that this pattern is not correct?

It doesn't work on SysV init either: "/etc/init.d/nginx start ;
/etc/init.d/nginx stop" is racy as it will leave ngnx running if it the
PID file isn't written by the time the stop command is used.

[...]

> Or may be it will be simpler to fix root cause of problem in systemd?

Well, I wish you good luck fixing SysV init scripts too. Before we
talk about "fixing systemd", let's talk how do you intend to make
"/etc/init.d/nginx start ; /etc/init.d/nginx stop" work correctly,
without races, without sometimes leaving nginx running, if you don't
wait for the PID file to be written safely before exiting.

Lennart

--
Lennart Poettering, Red Hat

=

Что ему ответить? Как сделать так, чтобы команда
"/etc/init.d/nginx start ; /etc/init.d/nginx stop"
работала без глюков на CentOS 6 ? Она ведь глючит.

Может быть действительно имеет смысл сделать
"wait for the PID file to be written safely before exiting"
и не брать для nginx пример с кривых и глючных демонов
у которых есть race conditions при старте/остановке?


Максим, можно ли сделать так, чтобы nginx соответствовал
тем требованиям которые предъявляет systemd к SysV Daemons?



https://www.freedesktop.org/software/systemd/man/daemon.html



Можно, я ж разве против?


А как это лучше всего сделать?

--
Best regards,
 Gena

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-23 Пенетрантность Илья Шипицин 
23 ноября 2017 г., 22:55 пользователь Maxim Dounin 
написал:

> Hello!
>
> On Thu, Nov 23, 2017 at 12:30:45PM -0500, S.A.N wrote:
>
> > > С точки зрения практики - паттерн "daemon(); write_pidfile();"
> > > используется чуть менее, чем везде, вплоть до соответствующих
> > > библиотечных функций.  Так что инициатива выглядит, скажем так,
> > > сомнительной.
> > >
> > > Проще всего, IMHO, это было бы заткнуть на уровне systemd,
> > > дожидаясь появления pid-файла при необходимости.
> >
> > Возможно я чего-то не понимаю, но для Systemd лучше вообще не указывать
> pid
> > файл, вместо Type=fork использовать Type=notify, это более гибкий вариант
> > сообщить Systemd что процесс готов к работе.
> >
> > Вот подробней, кстати PostgreSQL и PHP-FPM уже перешли на него.
> > https://www.freedesktop.org/software/systemd/man/systemd.
> service.html#Type=
>
> Нет, спасибо, собираться с systemd'шными библиотеками - это не к
> нам.
>
>
не совсем про systemd, скорее про пакеты

не пробовали вот такие хуки
https://fedoraproject.org/wiki/Packaging:Scriptlets#Systemd ?
(для pre, post скриптов)


> --
> Maxim Dounin
> http://mdounin.ru/
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-23 Пенетрантность Maxim Dounin 
Hello!

On Thu, Nov 23, 2017 at 12:30:45PM -0500, S.A.N wrote:

> > С точки зрения практики - паттерн "daemon(); write_pidfile();" 
> > используется чуть менее, чем везде, вплоть до соответствующих 
> > библиотечных функций.  Так что инициатива выглядит, скажем так, 
> > сомнительной.
> > 
> > Проще всего, IMHO, это было бы заткнуть на уровне systemd, 
> > дожидаясь появления pid-файла при необходимости.
> 
> Возможно я чего-то не понимаю, но для Systemd лучше вообще не указывать pid
> файл, вместо Type=fork использовать Type=notify, это более гибкий вариант
> сообщить Systemd что процесс готов к работе.
> 
> Вот подробней, кстати PostgreSQL и PHP-FPM уже перешли на него.
> https://www.freedesktop.org/software/systemd/man/systemd.service.html#Type=

Нет, спасибо, собираться с systemd'шными библиотеками - это не к 
нам.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-23 Пенетрантность Gena Makhomed 

On 23.11.2017 19:30, S.A.N wrote:


для Systemd лучше вообще не указывать pid файл


Не лучше. Если Type=forking то pid файл необходимо указывать всегда:
https://lists.freedesktop.org/archives/systemd-devel/2017-November/039831.html


вместо Type=fork использовать Type=notify, это более гибкий вариант
сообщить Systemd что процесс готов к работе.


Тогда не будет работать обновление исполняемого файла на лету:
http://nginx.org/ru/docs/control.html#upgrade

# service nginx upgrade
Starting new master nginx: [  OK  ]
Graceful shutdown of old nginx:[  OK  ]

--
Best regards,
 Gena

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-23 Пенетрантность Gena Makhomed 

On 23.11.2017 18:44, Igor Sysoev wrote:


Кстати, Lennart Poettering нашел еще одну ошибку в исходниках nginx:
https://lists.freedesktop.org/archives/systemd-devel/2017-November/039832.html



Интересно, откуда он это придумал про двойной fork()?


Скорее всего из книжки Richard W. Stevens
Advanced Programming in the UNIX Environment, 3rd Edition
https://www.amazon.com/Advanced-Programming-UNIX-Environment-3rd/dp/0321637739

Подробный ответ на stackoverflow с объяснением зачем двойной форк:
https://stackoverflow.com/a/31485256

Кстати, сама эта книжка
Advanced Programming in the UNIX Environment, 3rd Edition
в PDF формате на английском доступна для скачивания в интернете:
http://www.codeman.net/wp-content/uploads/2014/04/APUE-3rd.pdf
https://github.com/shihyu/Linux_Programming/blob/master/books/Advanced.Programming.in.the.UNIX.Environment.3rd.Edition.0321637739.pdf

--
Best regards,
 Gena

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-23 Пенетрантность S.A.N 
> С точки зрения практики - паттерн "daemon(); write_pidfile();" 
> используется чуть менее, чем везде, вплоть до соответствующих 
> библиотечных функций.  Так что инициатива выглядит, скажем так, 
> сомнительной.
> 
> Проще всего, IMHO, это было бы заткнуть на уровне systemd, 
> дожидаясь появления pid-файла при необходимости.

Возможно я чего-то не понимаю, но для Systemd лучше вообще не указывать pid
файл, вместо Type=fork использовать Type=notify, это более гибкий вариант
сообщить Systemd что процесс готов к работе.

Вот подробней, кстати PostgreSQL и PHP-FPM уже перешли на него.
https://www.freedesktop.org/software/systemd/man/systemd.service.html#Type=

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,277438,277473#msg-277473

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-23 Пенетрантность Maxim Dounin 
Hello!

On Thu, Nov 23, 2017 at 07:44:57PM +0300, Igor Sysoev wrote:

> > On 23 Nov 2017, at 19:28, Gena Makhomed  wrote:
> > 
> > Кстати, Lennart Poettering нашел еще одну ошибку в исходниках nginx:
> > https://lists.freedesktop.org/archives/systemd-devel/2017-November/039832.html
> 
> Интересно, откуда он это придумал про двойной fork()?
> 
> Во FreeBSD используется только один fork() что в 2017 году:
> https://svnweb.freebsd.org/base/head/lib/libc/gen/daemon.c?revision=326025=co
> что в 1994:
> https://svnweb.freebsd.org/base/head/lib/libc/gen/daemon.c?revision=1573=co

Двойной форк нужен на Линуксе, чтобы случайно не получить себе 
обратно controlling terminal.  Документировано, например, тут в 
man daemon(3) у glibc, 
http://man7.org/linux/man-pages/man3/daemon.3.html:

   The GNU C library implementation of this function was taken from BSD,
   and does not employ the double-fork technique (i.e., fork(2),
   setsid(2), fork(2)) that is necessary to ensure that the resulting
   daemon process is not a session leader.  Instead, the resulting
   daemon is a session leader.  On systems that follow System V
   semantics (e.g., Linux), this means that if the daemon opens a
   terminal that is not already a controlling terminal for another
   session, then that terminal will inadvertently become the controlling
   terminal for the daemon.

Смысла это делать в nginx'е - скорее нет, IMHO.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-23 Пенетрантность Maxim Dounin 
Hello!

On Thu, Nov 23, 2017 at 06:28:55PM +0200, Gena Makhomed wrote:

> On 23.11.2017 17:37, 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();", и при таком подходе - ситуацию не 
изменить.

> > Впрочем, если верить ответу тут:
> > https://lists.freedesktop.org/archives/systemd-devel/2017-November/039825.html
> 
> > то соответствующее сообщение можно смело игнорировать, и systemd
> > на самом деле умеет дожидаться создания pid-файла.  То есть вопрос
> > лишь в том, что при этом systemd пишет в лог.
> 
> Не надо верить тому, что говорит Michael Chapman - он ошибается.
> systemd не ждет появления pid-файла, я это проверял по исходникам.
> 
> Лучше верить тому, что говорит Lennart Poettering, автор systemd:
> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039833.html
> 
> Всегда надо указывать корректный PIDFile= для сервисов Type=forking:
> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039831.html
> 
> Максим, можно ли сделать так, чтобы nginx соответствовал
> тем требованиям которые предъявляет systemd к SysV Daemons?
> 
> https://www.freedesktop.org/software/systemd/man/daemon.html

Можно, я ж разве против?

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-23 Пенетрантность Igor Sysoev 
> On 23 Nov 2017, at 19:28, Gena Makhomed  wrote:
> 
> Кстати, Lennart Poettering нашел еще одну ошибку в исходниках nginx:
> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039832.html

Интересно, откуда он это придумал про двойной fork()?

Во FreeBSD используется только один fork() что в 2017 году:
https://svnweb.freebsd.org/base/head/lib/libc/gen/daemon.c?revision=326025=co
что в 1994:
https://svnweb.freebsd.org/base/head/lib/libc/gen/daemon.c?revision=1573=co


-- 
Igor Sysoev
http://nginx.com

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-23 Пенетрантность Gena Makhomed 

On 23.11.2017 17:37, 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


Впрочем, если верить ответу тут:
https://lists.freedesktop.org/archives/systemd-devel/2017-November/039825.html



то соответствующее сообщение можно смело игнорировать, и systemd
на самом деле умеет дожидаться создания pid-файла.  То есть вопрос
лишь в том, что при этом systemd пишет в лог.


Не надо верить тому, что говорит Michael Chapman - он ошибается.
systemd не ждет появления pid-файла, я это проверял по исходникам.

Лучше верить тому, что говорит Lennart Poettering, автор systemd:
https://lists.freedesktop.org/archives/systemd-devel/2017-November/039833.html

Всегда надо указывать корректный PIDFile= для сервисов Type=forking:
https://lists.freedesktop.org/archives/systemd-devel/2017-November/039831.html

Максим, можно ли сделать так, чтобы nginx соответствовал
тем требованиям которые предъявляет systemd к SysV Daemons?

https://www.freedesktop.org/software/systemd/man/daemon.html

--
Best regards,
 Gena

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-23 Пенетрантность Maxim Dounin 
Hello!

On Thu, Nov 23, 2017 at 03:49:43PM +0200, Gena Makhomed wrote:

> On 22.11.2017 19:43, Maxim Dounin wrote:
> 
> >> systemd: PID file /var/run/nginx.pid not readable (yet?) after start.
> 
> >> Можно ли как-то исправить поведение nginx,
> >> чтобы systemd не флудил в логи сообщениями об ошибках?
> 
> > С точки зрения абстрактного счастья для всех даром - наверное,
> > поведение systemd логично, и на момент выхода запущенного процесса
> > pid-файл должен уже существовать.
> > 
> > С точки зрения практики - паттерн "daemon(); write_pidfile();"
> > используется чуть менее, чем везде, вплоть до соответствующих
> > библиотечных функций.  Так что инициатива выглядит, скажем так,
> > сомнительной.
> 
> Спросил об этом в списке рассылки systemd-devel:
> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039812.html
> 
> Идея переписать systemd там энтузиазма не вызвала:
> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039820.html
> 
> Более того, мне прислали ссылку на официальную документацию systemd:
> 
> Many other deficiencies with the BSD daemon() function
> are documented in systemd's daemon(7) manpage.
> 
> В systemd's daemon(7) manpage очень подробно расписано
> как должны вести себя SysV Daemons при работе с systemd.
> И очевидно, что nginx этим требованиям не соответствует.
> 
> Original process должен вызывать exit() только после того,
> как будет полностью завершена инициализация daemon process,
> в частности, после того как daemon process создаст свой pid файл.

Это, что называется, всё очень интересно, но вызывает сомнение 
успех подобных рекомендаций.  Особенно с учётом отсутствия 
каких-либо внятных примеров того, что же использовать вместо 
daemon(3).  О чём я, собственно, и писал выше.

Впрочем, если верить ответу тут:

https://lists.freedesktop.org/archives/systemd-devel/2017-November/039825.html

то соответствующее сообщение можно смело игнорировать, и systemd 
на самом деле умеет дожидаться создания pid-файла.  То есть вопрос 
лишь в том, что при этом systemd пишет в лог.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-23 Пенетрантность Gena Makhomed 

On 22.11.2017 19:43, Maxim Dounin wrote:


systemd: PID file /var/run/nginx.pid not readable (yet?) after start.



Можно ли как-то исправить поведение nginx,
чтобы systemd не флудил в логи сообщениями об ошибках?



С точки зрения абстрактного счастья для всех даром - наверное,
поведение systemd логично, и на момент выхода запущенного процесса
pid-файл должен уже существовать.

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


Спросил об этом в списке рассылки systemd-devel:
https://lists.freedesktop.org/archives/systemd-devel/2017-November/039812.html

Идея переписать systemd там энтузиазма не вызвала:
https://lists.freedesktop.org/archives/systemd-devel/2017-November/039820.html

Более того, мне прислали ссылку на официальную документацию systemd:

Many other deficiencies with the BSD daemon() function
are documented in systemd's daemon(7) manpage.

В systemd's daemon(7) manpage очень подробно расписано
как должны вести себя SysV Daemons при работе с systemd.
И очевидно, что nginx этим требованиям не соответствует.

Original process должен вызывать exit() только после того,
как будет полностью завершена инициализация daemon process,
в частности, после того как daemon process создаст свой pid файл.


Проще всего, IMHO, это было бы заткнуть на уровне systemd,
дожидаясь появления pid-файла при необходимости.


Кстати, дожидаться pid-файла - это не совсем тривиальная задача,
ведь nginx пишет свой pid-файл не атомарно. Может же быть так,
что файл уже появился, но он будет нулевого размера и попытка
прочитать из него pid завершится ошибкой? Или он будет частично
записан и тогда из pid-файла прочитается pid другого процесса?

Можно ли будет исправить поведение nginx чтобы он соответствовал
требованиям к SysV Daemons из systemd's daemon(7) manpage?

Поведение systemd изменить не получится, я уже пробовал.

--
Best regards,
 Gena

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-22 Пенетрантность Maxim Dounin 
Hello!

On Tue, Nov 21, 2017 at 10:46:58PM +0200, Gena Makhomed wrote:

> Здравствуйте, All!
> 
> nginx установлен из официального репозитория nginx.org, CentOS 7.4
> 
> В логах вот такое наблюдается при перезапуске nginx 1.13.6:
> 
> systemd: Starting nginx - high performance web server...
> nginx: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
> nginx: nginx: configuration file /etc/nginx/nginx.conf test is successful
> systemd: Failed to read PID from file /var/run/nginx.pid: Invalid argument
> systemd: Started nginx - high performance web server.
> 
> И вот такое при запуске nginx 1.13.7:
> 
> systemd: Starting nginx - high performance web server...
> systemd: PID file /var/run/nginx.pid not readable (yet?) after start.
> systemd: Started nginx - high performance web server.
> 
> Как это можно победить, чтобы в логах такого не было?
> 
> Рекомендуют вот такой workaround: https://stackoverflow.com/a/42084804
> И еще вот такое нашлось заодно: https://stackoverflow.com/a/42555993
> 
> Но это наверное неправильно будет, добавлять sleep 0.1 в юнит-файл?
> 
> Обе эти ошибки возникают в systemd функции service_load_pid_file()
> https://github.com/systemd/systemd/blob/master/src/core/service.c#L815
> Когда systemd не может прочитать pid-файл.
> 
> Насколько я понял из комментариев в функции service_enter_start()
> https://github.com/systemd/systemd/blob/master/src/core/service.c#L1909
> 
> /* For forking services we wait until the start
>   * process exited. */
> 
> И в функции service_sigchld_event():
> https://github.com/systemd/systemd/blob/master/src/core/service.c#L2959
> 
> /* Forking services may occasionally move to a new PID.
>   * As long as they update the PID file before exiting the old
>   * PID, they're fine. */
> 
> Systemd считает что сервис запустился
> после того как start process exited ?
> 
> А у nginx получается так, что start process exited,
> а pid файл еще не создан и это создает проблемы systemd?
> 
> Можно ли как-то исправить поведение nginx,
> чтобы systemd не флудил в логи сообщениями об ошибках?

С точки зрения абстрактного счастья для всех даром - наверное, 
поведение systemd логично, и на момент выхода запущенного процесса 
pid-файл должен уже существовать.

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

Проще всего, IMHO, это было бы заткнуть на уровне systemd, 
дожидаясь появления pid-файла при необходимости.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-21 Пенетрантность Gena Makhomed 

Здравствуйте, All!

nginx установлен из официального репозитория nginx.org, CentOS 7.4

В логах вот такое наблюдается при перезапуске nginx 1.13.6:

systemd: Starting nginx - high performance web server...
nginx: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: nginx: configuration file /etc/nginx/nginx.conf test is successful
systemd: Failed to read PID from file /var/run/nginx.pid: Invalid argument
systemd: Started nginx - high performance web server.

И вот такое при запуске nginx 1.13.7:

systemd: Starting nginx - high performance web server...
systemd: PID file /var/run/nginx.pid not readable (yet?) after start.
systemd: Started nginx - high performance web server.

Как это можно победить, чтобы в логах такого не было?

Рекомендуют вот такой workaround: https://stackoverflow.com/a/42084804
И еще вот такое нашлось заодно: https://stackoverflow.com/a/42555993

Но это наверное неправильно будет, добавлять sleep 0.1 в юнит-файл?

Обе эти ошибки возникают в systemd функции service_load_pid_file()
https://github.com/systemd/systemd/blob/master/src/core/service.c#L815
Когда systemd не может прочитать pid-файл.

Насколько я понял из комментариев в функции service_enter_start()
https://github.com/systemd/systemd/blob/master/src/core/service.c#L1909

/* For forking services we wait until the start
 * process exited. */

И в функции service_sigchld_event():
https://github.com/systemd/systemd/blob/master/src/core/service.c#L2959

/* Forking services may occasionally move to a new PID.
 * As long as they update the PID file before exiting the old
 * PID, they're fine. */

Systemd считает что сервис запустился
после того как start process exited ?

А у nginx получается так, что start process exited,
а pid файл еще не создан и это создает проблемы systemd?

Можно ли как-то исправить поведение nginx,
чтобы systemd не флудил в логи сообщениями об ошибках?

--
Best regards,
 Gena

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru