Mixing syslog configs leads to logging chaos

[Bill Erickson]

OpenSRF 2.4 / affects all versions.

Applications running together atop OpenSRF with conflicting syslog configurations can lead to inconsistent logging. This happens, for example, when running SIPServer with Evergreen. Each has its own syslog configuration, leading to inconsistent syslog formats (e.g. PID may or may not appear in the logs) and facility, depending on which component calls openlog() last. Logs start in one place and end up somewhere else.

I propose to give OpenSRF a toggle which tells it to avoid modifying syslog if it has been (or will be) managed from another context. This may be best handled with an environment variable (OSRF_ADOPT_SYSLOG) which, when set, tells Logger.pm to avoid any calls to openlog() and closelog() and to avoid overwriting the syslog facility when calling syslog().

(Note, I was unable to find any tool within syslog itself to detect if openlog has already been called).

With this, you might start SIP like so:

OSRF_ADOPT_SYSLOG=1 oils_ctl.sh -a start_sip

Here, SIPServer makes the initial openlog() call, then all SIP logs and Evergreen/OpenSRF client logs (running from within SIPServer) go to the same place and have the same syslog ident and facility.

Branch en route.

[Bill Erickson (berick)]

http://git.evergreen-ils.org/?p=working/OpenSRF.git;a=shortlog;h=refs/heads/user/berick/lp1473479-syslog-adoption

[Galen Charlton (gmc)]

Pushed to master for inclusion in 2-5-alpha. Thanks, Bill!