Handling old log mechanisms

The daemontools way of logging for many years has been to just write to standard error. After a decade and a half of pressure, quite a few services can be set up to work this way nowadays. Many services can thus have their logging handled independently of that of other services, by a dedicated "log" service running behind a security partition, removing the problems of centralized logging such as vulnerability to flooding attacks, a single I/O bottleneck, and mixture of trusted and untrusted content. But there remain some diehards that cannot be configured this way.

Component commands

The klog-read and syslog-read commands form the bases of services that can handle old log mechanisms. klog-read is a simple UCSPI program that expects its standard input to be stream-based. syslog-read is a simple UCSPI program that expects its standard input to be datagram-based.

They are intended to be more secure than the old-style rsyslog or Wettstein syslog programs.

They are also simpler, by design. They leave off some of the bells and whistles of those programs, which are less necessary with this toolset or approached an entirely different way. Logs are already distributed into multiple sets, by the very nature of dedicated "log" services; logs are already autorotated; logs are already strictly size-capped. All of these are the domain of a "log" service that is security-partitioned from the services running klog-read or syslog-read.

They also build upon service management mechanisms. Not providing (for example) UDP log service is a simple matter of stopping and disabling the udp-syslog-read service with service management tools, just like any other service.

Kernel logging

Plumbed together with fifo-listen, klog-read forms the klog service. This service listens to the operating system kernel's log device (/dev/kmsg on Linux, /dev/klog on the BSDs) and writes out all that it receives. It feeds an ordinary log service, so kernel logs end up in a normal, automatically rotated, strictly size capped, set of log files like any other.

"syslog" logging

Plumbed together with local-datagram-socket-listen, syslog-read forms the local-syslog-read service. This service listens to the GNU C library's log socket (/dev/log on Linux, /run/log on the BSDs) and writes out all that it receives.

Plumbed together with local-datagram-socket-listen, syslog-read forms the systemd-syslog-read service. This service listens to the systemd-journal's log socket (/run/systemd/journal/syslog) and writes out all that it receives.

Plumbed together with udp-socket-listen, syslog-read forms the udp-syslog-read service. This service listens to the conventional "syslog" UDP port and writes out all that it receives.

They all feed ordinary log services, so local and remote logs end up in a normal, automatically rotated, strictly size capped, set of log files like any other. The services are entirely independent, though. This has various security benefits.