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