Re: глобальные директивы error_log и pid

[Maxim Dounin]

Hello!

On Sat, Nov 13, 2010 at 09:19:26PM +0200, Gena Makhomed wrote:

> On 13.11.2010 19:53, Maxim Dounin wrote:
> 
> >>>It would be good to have something like '-e' switch instead,
> >>>similar to '-p' for prefix (actually, I even have it in my TODO
> >>>since 0.7.53, but ENOTIME).
> >>
> >>примерно так сейчас Apache и делает:
> >>
> >># httpd -h 2>&1 | grep error
> >>   -e level           : show startup errors of level (see LogLevel)
> >>   -E file            : log startup errors to file
> >>
> >>но это не очень красивое решение, потому что инофрмация тут дублируется,
> >>да и с pid-файлом будут аналогичные проблемы, тогда еще один ключ надо?
> 
> >С pid-файлом таких проблем быть не может - он создаётся уже после
> >заверешения парсинга конфига.
> 
> в исходном сообщении от Hongli Lai из англоязычной рассылки было:
> 
> "have a setup in which many different users use the same Nginx
> executable, but each one with a different config file
> and error log file"
> 
> а чтобы управлять различными экземплярами nginx, которые запущены
> из одного бинарника и отличаются только конфигом и init-скриптом,
> их надо уметь различать. а различать их можно только через PID.
> 
> вариант парсить в инит-скрипте вывод "ps -ef", чтобы определить
> pid необходимого nginx master процесса - это достаточно недоубно.
> вариант pidfile=`nginx -c $config -G pid` мне видится тут лучшим.
> 
> хотя бы потому, что на разных системах нужно указывать различные
> параметры командной строки для ps, да формат вывода будет отличаться.
> 
> или придется добавлять к nginx еще один параметр командной строки -P
> 
>   -P pidfile    : set pid file name (default: /var/run/nginx.pid)
> 
> или два раза дублировать имя pid-файла - в init-скрипте и в конфиге.
> но если информация где-то дублируется несколько раз, то рано или поздно
> будут возникать проблемы у пользователей, когда они изменили директиву
> pid в конфиге, но забыли изменить параметр командной строки nginx
> в init-скрипте, или наоборот.

Pid можно задать в конфиге или через -g "pid $pidfile;".  Никаких 
дополнительных ключей для того чтобы его задавать - вводить не 
нужно.

> >>я придумал более красивое решение:
> >>
> >>1. nginx определяет имя конфигурационного файла из параметра -с
> >>    или используется built-in значение, если ключ -c не определен.
> >>
> >>2. вызывается helper-функция, которая парсит конфигурационный файл,
> >>    считывая только несколько глобальных директив: error_log и pid,
> >>    если эти две директивы встретились в конфиге, парсинг прекращается.
> >>    директива include также игнорируется, как и возможные ошибки разбора.
> >
> >Вопрос на самом деле очень простой: если мы хотим куда-то
> >логировать ошибки открытия/парсинга конфига - то должны откуда-то ещё
> >получить место для логирования этих ошибок.
> >
> >Сейчас это "откуда-то ещё" - --error-log-path из бинарника (и
> >префикс из бинарника или из ключа -p, если путь в --error-log-path
> >относительный).
> >
> >Предлагаемое решение в качестве "откуда-то ещё" сделать
> >дополнительный sloppy-parser конфига мне кажется крайне
> >сомнительным.
> 
> по такому же приципу работают и современные операционные системы -
> для того чтобы загрузить ядро необходимо получить доступ к файловой
> системе, а чтобы получить доступ к файловой системе - надо чтобы ядро
> уже было запущено. и загрузчик операционной системы выполняет роль
> такого "упрощенного парсера", который умеет только читать файлы.

Угу, и я даже и говорить не хочу сколько в этом месте имеется в 
результате геморроя.

> тем более, что если в конфиге нет директивы error_log,
> то все работает как и раньше, используя biult-in defaults.
> 
> а если в конфиге nginx указана директива error_log,
> тогда все работает ожидаемым для пользователя образом,
> это принцип "наименьшего сюрприза". иначе - как и сейчас,
> будет очень много вопросов в списках рассылки, почему они
> указали директиву error_log в конфиге, а nginx пишет не туда.

Я не говорил, что мне не нравится идея брать error_log из конфига.  
Я говорил, что мне не нравится идея делать sloppy-parser этого 
конфига.  Это будет приличный кусок дополнительного кода, нужного 
только для одной задачи - вытащить error_log.

И ладно бы это решало проблему, так ведь полностью оно её не 
решает: если конфиг не открылся или там syntax error до 
error_log'а - всё равно придётся сваливаться в --error-log-path.  
А мне, например, нужно *вообще никогда* не трогать 
--error-log-path, потому как тот же test suite предполагает 
возможность запуска на произвольно скомпилированном бинарнике без 
каких-либо последствий для системы.

> >>5. добавляется всего один параметр командной строки -G
> >>
> >>   -G directive  : get global directive from configuration file
> >>
> >>это необходимо для того, чтобы можно было seamless использовать
> >>один бинарник nginx для запуска нескольких независимых instances:
> >>
> >>pidfile=`nginx -G pid`
> >>
> >>и дальше init-script знает, какой pid file отвечает этому экземпляру.
> >>причем, вся конфигурация nginx находится только в одном месте - конфиге.
> 
> >Just a side note: это не имеет ну никакого отношения к проблеме
> >error_log'а.
> 
> верно.
> 
> это другая проблема, которая появится у Hongli Lai
> после того как он решит эту проблему с erorr_log`ом.
> 
> я просто уже прошелся по всем этим граблям несколько раз,
> когда пытался сделать несколько nginx instances на одном binary.

Ходить по граблям не запретишь, но в отличие от error_log'а - 
проблемы с заданием pid просто нет.

Есть небольшое неудобство, заключающееся в необходмости задавать 
его и в конфиге и в init-скрипте (либо только в init-скрипте, но 
соответственно отдельно от остального конфига).

Я лишь указал на проблемы предлагаемого подхода разрешния данного 
неудобства.

[...]

Maxim Dounin