Re: "Правильные" демоны - не демоны?
Alexey Pechnikov -> debian-russian@lists.debian.org @ Fri, 28 Aug 2009 00:02:54 +0400:
>> > Далее, зачем нужна встроенная работа с syslog, когда можно
>> > передавать в лог stdout & stderr через пайп (связку программы с
>> > логирующей утилитой могут обеспечить runit, daemontools, etc.,
>> > если не хочется вручную перенапрявлять вывод).
>>
>> Куда именно перенаправить? syslog умеет очень быстро фильтровать и
>> сортировать сообщения, отправляя их куда надо и как надо. Не
>> обязательно в файл.
AP> Вот только чтобы сообщения передать в сислог, нужно код программы
AP> переделывать, заменяя вывод в stdout/stderr на работу с
AP> сислогом.
Открою секрет. Если сразу криво не делать, то потом переделывать не
придется.
Если сделать в программе функцию log_message(int verbosity_level, const
char *format, ...), то переделывать, когда ты узнаешь о том, какой
вообще бывает логгинг, тебе придется только эту функцию.
Правда, да, параметр verbosity_level в ней таки лучше предусмотреть. А
для этого лучше бы сразу знать, какой бывает логгинг. Но в крайнем
случае можно и пережить.
А если у тебя весь логгинг сделан как printf(format, ...) по телу
программы, то... Первое, что я скажу, увидев такое в программе - "я
полагаю, дешевле будет ее выкинуть и написать заново, ибо это в ней,
скорее всего, не самое ужасное".
AP> Кроме того, для того, чтобы вывод пользовательской программы
AP> направить в отдельный файл, надо отредактировать конфиг сислога и
AP> перезапустить его - и все это с правами рута. А потом еще нужно
AP> настроить ротацию этого лога, отредактировав еще один конфиг...
А это ничего, что эти конфиги могут быть на разных машинах? И именно
поэтому они разные?
AP> На винду все больше смахивает, а не на юникс с цепочками утилит и
AP> пайпами.
В винде, кстати, пайпы предоставляют функциональность message
passing... Отсутствие которой (и, соответственно, отсутствие удобной
работы с нею) является недостатком юниксовой архитектуры.
Правда, в винде, помнится, удобных инструментов работы с пайпом вообще
нет :-) tcl, к примеру, на них работать не умеет :-(
--
If it's there and you can see it---it's real
If it's not there and you can see it---it's virtual
If it's there and you can't see it---it's transparent
If it's not there and you can't see it---you erased it!
IBM poster explaining virtual memory, circa 1978
Reply to: