Unclear cause when Rotonda exits due to missing syslogd
ximon18 opened this issue · comments
If Rotonda is configured to log to syslog (as is the case with the etc/rotonda.conf.system-service installed by DEB/RPM packages) and a syslog daemon is not available, Rotonda exits without a clear explanation of why. This should instead exit with a helpful log message.
The root cause of this seems to be that when the log target is set to syslog the code tries UNIX domain socket, falls back to TCP to 127.0.0.1 port 601 and after that falls back to UDP to 127.0.0.1 514, and that final fallback being UDP doesn't fail even if there is no syslog.
One possible improvement would be to log fallback to different syslog transports when the primary UNIX domain socket is not found, resulting in something like this appearing in the systemd journal for the unit or on stderr if running manually from the command line:
# journalctl --unit rotonda
...
Oct 30 23:12:15 rusty systemd[1]: Started rotonda.service - Rotonda.
Oct 30 23:12:15 rusty rotonda[1140]: Syslog not available via UNIX socket, falling back to tcp://127.0.0.1:601
Oct 30 23:12:15 rusty rotonda[1140]: Syslog not available via TCP socket, falling back to udp://127.0.0.1:514
Oct 30 23:12:15 rusty rotonda[1140]: Warning: Logs may be lost if no syslog daemon is listening at udp://127.0.0.1:514 !
Oct 30 23:12:15 rusty systemd[1]: rotonda.service: Main process exited, code=exited, status=1/FAILURE
Oct 30 23:12:15 rusty systemd[1]: rotonda.service: Failed with result 'exit-code'.
Oct 30 23:12:15 rusty systemd[1]: rotonda.service: Scheduled restart job, restart counter is at 5.
Oct 30 23:12:15 rusty systemd[1]: Stopped rotonda.service - Rotonda.
So, the actual error message is still lost because it was sent to syslog over UDP while there is no syslog daemon listening on that UDP socket address, but at least you know where it was trying to log to.
Done via #52.