# 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.