Re: [PATCH] daemon: add --no-syslog to undo implicit --syslog

[Lucas Werkmeister <mail@lucaswerkmeister.de>]

On 24.01.2018 19:33, Junio C Hamano wrote:
> Lucas Werkmeister <mail@lucaswerkmeister.de> writes:
> 
>>> Moreover, --detach completely dissociates the process from the
>>> original set of standard file descriptors by first closing them and
>>> then connecting it to "/dev/null", so it will be nonsense to use this
>>> new option with it.
>>
>> Ah, I wasn’t aware of that – so with --detach, --no-syslog would be
>> better described as “disables all logging” rather than “log to stderr
>> instead”. IMHO it would still make sense to have the --no-syslog option
>> (then mainly for use with --inetd) as long as its interaction with
>> --inetd is properly documented.
> 
> Because "--detach --no-syslog" is a roundabout way to ask for
> sending the log to _nowhere_, I actually would say that "nonsense"
> is a bit too strong a word for the combination of your thing with
> "--detach".
> 
> It might make more sense to introduce a new "--send-log-to=<dest>"
> option, where the destination can be one of: syslog, stderr, none.
> 
> The you can make the current "--syslog" option a synonym to
> "--send-log-to=syslog".  The internal variable log_syslog would
> probably become
> 
> 	enum log_destination { 
> 		LOG_TO_NONE = -1,
> 		LOG_TO_STDERR = 0,
> 		LOG_TO_SYSLOG = 1,
> 	} log_destination;
> 
> and wherever the current code assigns 1 to log_syslog, you would be
> setting it LOG_TO_SYSLOG.
> 
> Then those who want no log can express that wish in a more direct
> way, i.e. "daemon --send-log-to=none", perhaps.
> 
> Such an approach leaves open room for future enhancement.  It is not
> too far-fetched to imagine something like:
> 
> 	git daemon --send-log-to=/var/log/git-daemon.log
> 
> by introducing the fourth value to "enum log_destination"; perhaps
> the file is opened and connected to stderr to accept the logs,
> combined with a new feature that tells the daemon to close and
> reopen the log file when it receives a HUP or something like that.

Sounds interesting… do you think it would be worth it supporting
multiple destinations? Right now this could be implemented fairly easily
by making log_destination a bit field (and --syslog would then imply
--send-log-to=syslog --no-send-log-to=stderr or something like that). On
the other hand, that doesn’t allow for this nice trick of reusing the
stderr fd for a log file in case of future enhancement.