syslog configuration breaks log viewing interfaces

[btubbs]

If you configure a program to log to 'syslog' instead of providing a file path, then you are no longer able to view logs in the web interface, XML RPC interface, or supervisorctl shell. Ouch!

I suggest changing the syslog configuration method to be something you can do in addition to normal file logging instead of it being an exclusive alternative. Then Supervisor's log streaming features should be able to work normally.

So let's have two new program config options:

stdout_syslog
stderr_syslog

Setting them to true will make log messages go to syslog in addition to going to files specified by stdout_logfile and stderr_logfile.

We can continue to support setting stdout_logfile and stderr_logfile to 'syslog', so as to avoid breaking users' existing configurations, though for cleanliness I think it'd be good to raise a deprecation warning.

[jaraco]

I feel like this conflates two issues - syslog logging superseding file logging, and enabling log viewing interfaces independent of file logging. However, from a practical perspective, I agree the proposed solution solves the first issue and doesn't compete with the latter, so let's do it.

[jaraco]

I'll propose a different solution - rather than add new boolean flags indicating to log to syslog, create two new options:

stdout_log_targets
stderr_log_targets

These config values would take a comma-separated list of targets. The default value for each would be 'file', which will invoke the default behavior. The initial implementation would include one additional target, 'syslog', which indicates to send logs to syslog. Since there can be multiple targets, one could log to both file and syslog ("file,syslog").

[jaraco]

I notice now that there's a third mode currently supported by supervisord, streaming logs, so I suggest a third option for log_targets: 'stream'

[jaraco]

After a great deal of investigation and trials, I've concluded that this problem is much easier said than done. The child processing logging functionality is scattered over several modules, including options, dispatchers, and logging (not to mention the docs). For example, if no filename is specified, when the config is read (options.py:837), a special flag is placed for the filename. Later, after the process has a process ID, that value is resolved to an actual file name and created (options.py:1747) and the config is updated.

Due to the amount of code that logging to a file touches and the limited value adding other logging handlers might have, I'm inclined to simply follow the original suggestion and add another parameter 'stdout_syslog' and allow it to be True or False, independent of the value of stdout_logfile.

Otherwise, a substantial effort will be required if the meaning of stdout_logfile is to be changed at all.

[vlcinsky]

This seems to be resolved pull request #241 (thanks jaraco).
Looking forward to see it released.

[mnaberez]

Fixed in 2ab5364.