Allow target file for NUT_DEBUG_SYSLOG

[desertwitch]

Kicking off an enhancement discussion with this, I think it'd be great if NUT_DEBUG_SYSLOG from issue #2394 and PR #2550 would also offer:

• All output to be directed to a file instead (while remaining detached)
• All output to be directed to SYSLOG or STDERR + a file additionally (while remaining detached)

This would make it easier to direct users to gather debugging output and/or not have NUT pollute the SYSLOG from a single setting, without having to catch all various NUT daemons from the SYSLOG side (and having to re-configure the SYSLOG daemon for that, which may be harder). Ideally this could be seamlessly switched at runtime via this environment variable?

This would also allow for (automated) diagnosis mechanisms (e.g. within NUT plugins for Unraid, Home Assistant, ...), sampling logs into a separate file for X minutes (switching this environment variable back and forth) to include in debug packages...

[jimklimov]

As far as I remember the code (mostly in common.c), currently logging depends on having the bits for stderr and/or syslog raised in an internal flag. Makes sense that a bit for a file could be managed similarly.

The generic problems to solve about this are:

• remembering the file name,
• settable at run-time (upsrw ... driver.logfile=xxx) along with driver.debug level, for the support scenarios noted above?
• closing/re-opening upon SIGHUP (common but not explicit signal for log rotation) which might double as config reload - could be undesirable if config is being edited and is broken, or some values land into it that are not reloadable and could cause driver exit/restart,
• ...doing both of the above reliably when chrooted - do we normally log inside the chroot or outside it?
• decide if we keep the logging file handle open, or re-open for each message (FS costs, flushing upon close => I/O costs and wear); generally how often do we flush (and should the daemon do so e.g. on timer?) so the last 4K-16K of logs are not lost in a crash, and generally promptly seen with tail -f etc. (does opening in text mode reliably flush after each \n?)

[jimklimov]

On a related note, the win32 implementation of open_syslog() actually prepares work with the Windows Event Log...

So far nobody complained, but technically one could use real syslog also with Windows, whether to send to a locally running log sink or perhaps to a common sink on an external machine - so perhaps separate bits for Windows Event Log vs. real syslog while running on Windows can be reasonable too. Although note, the openlog()/syslog() POSIX commands this currently relies on do not have any parameters for an external log sink (assuming a localhost logger, or whatever the standard library would route to). Perhaps instead an "offsite syslog" (along with remembered host, port, schema tcp vs udp) could be the new bit in the mask, keeping whatever is there now "as is", and adding to it.