ubc: logging to rsyslogd has problems

Dropping networked logging as per RFC5424 and forcing everybody to use files again by "reworking the logging" on the using side is a completely wrong solution to that perceived problem, which has to do with a particular syslog demon.

There are more than enough syslog demons implementations around - you dont like a particular demon, replace it by another one - syslog-ng, whatever. Take your pick.

If anything, this project needs less logging "mechanisms", not yet another one - in particular as embedded RT platforms with - not necessarily writable - filesystems are around the corner.

Opposed - wrong solution approach.

First, the relevant rsyslogd documentation on this matter [1,2] may or may not be helpful.

AFAICT, this issue is about creating a default config that's suitable for newbies while at the same time providing flexibility for advanced configurations.

The reason to put LCNC logs into /var/log/linuxcnc.log is to concentrate them in one place easy for newbies to transfer to e.g. pastebin for others to help.

The reason to write to syslog is to create flexibility, for example in embedded systems that lack writeable local storage, or in larger environments with many LCNC instances and centralized/remote logging/monitoring.

IMO, this flexibility will become increasingly important as LCNC is used on embedded platforms and finds new applications. Syslog functionality should be preserved in any case. I see two solutions:

One, allow writing to files as a workaround, if in fact rsyslogd is really broken (nobody has yet demonstrated that they actually read the manual). This has precedents, e.g. Apache, which allows logging either to a file or to syslog [3].

Two, if 'make install' must assume that someone who has managed to install all deps, compile LCNC from source, and install it might still be a newbie, then make reasonable default settings. In case they're not newbies, then they can go back and fix syslog settings as they please (and these should not be clobbered at the next 'make install'). The same applies to .deb/.rpm packages, where it seems more reasonable to assume the installer could be a newbie.

As for cradek's patch [4], it looks fine as a POC for logging to a file. To get my approval, it needs configurability plumbed in. I would pull the 'fd' argument out of rtapi_syslog(), if possible, and let rtapi_syslog.c keep track of that internally. The rtapi_openlog() and rtapi_closelog() functions should be solely responsible for setting up 'fd'. Configuration should come from the rtapi.ini [global] section and specify either a logging facility or a filename (or stderr?), with a reasonable default.

I don't quite understand Seb's question about feature and integration branches [5], but I don't see why this issue holds up RTOS support. Solution "Two" above already exists in the integration branch, it works, and is the best we can do for newbies on standalone installs. Good enough for now, unless I'm missing something. Solution "One" is halfway implemented in cradek's feature branch and IMO would be a valuable addition. When that feature branch is ready, it should be integrated.

[1] http://www.rsyslog.com/doc/rsconf1_includeconfig.html
[2] http://www.rsyslog.com/doc/rsconf1_resetconfigvariables.html
[3] http://httpd.apache.org/docs/2.2/mod/core.html#errorlog
[4] http://timeguy.com/cradek-files/emc/0001-POC-Log-to-a-file-cleared-each-run-instead-of-syslog.patch
[5] http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-02-11.html#20:58:10

Further discussion on IRC:

http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-02-14.html#15:34:10

Main points:

• For now, installing the rsyslog.d config file is good enough
• The current file might be improved by resetting rate limiting back to the distro default
  • This may clobber manually entered settings
  • However, it's the best we can do for newbies, and those who manually edit may do so again to fix
  • (Is this possible? The rsyslogd 5.8.11 docs don't describe $SystemLogRateLimitInterval and $SystemLogRateLimitBurst directives)
• It should not be the job of 'make install' to install the rsyslog.d file
  • Log configuration is distro-dependent and should be the job of the package system
• cradek's log-to-file feature will include ability configure log output to either file or syslog
  • Addresses the 'flexibility' issue