1 Background and purpose

svlogd is a log management daemon associated with the daemontools suite of service supervision tools. It is used in Unix-like environments to receive log data from supervised services and write that data to persistent log files. Its design emphasizes small, composable components and predictable behavior rather than a large centralized logging framework.

The program is commonly employed in setups where services are kept separate from their log handling logic. In such arrangements, svlogd serves as the dedicated logging companion to a service supervisor, allowing log capture, file rotation, and basic formatting to occur automatically with minimal administrative overhead.

1.1 Role in the daemontools ecosystem

Within the daemontools model, svlogd belongs to the logging side of service management. It typically runs as a companion process for a supervised service, reading the service’s standard output or error stream through a pipe and storing the resulting messages in a structured log directory.

This role complements the supervision philosophy of daemontools, in which long-running tasks are broken into small, manageable parts. The application process handles its own work, while svlogd handles log persistence and rotation. The separation helps keep services simpler and reduces the need for built-in logging features inside each program.

1.2 Problems it is designed to solve

svlogd is designed to address several common operational issues. One is uncontrolled log growth, which can consume disk space if files are never rotated or removed. Another is the difficulty of maintaining consistent log output across many services without writing custom scripts for each one.

It also helps standardize file handling. Rather than relying on ad hoc shell redirection, administrators can use a repeatable logging process that appends to files, rotates them when needed, and preserves older entries in an orderly way. This makes routine administration more predictable and reduces the chance of accidental log loss.

1.3 Typical use cases

svlogd is often used on servers that favor lightweight tooling and explicit configuration. It is well suited to hosting environments, small infrastructure deployments, and systems in which each service is managed by a separate supervision tree.

It is also useful where logs are meant to remain local and simple to inspect. Administrators may use it for web services, mail components, background workers, or other daemons that produce steady streams of text output. Because its behavior is scriptable and deterministic, it fits well into automated provisioning and maintenance workflows.

2 Operation

svlogd operates by receiving log records from a supervised service, processing those records according to its configuration, and writing them into one or more files in a log directory. The process is continuous and generally requires little direct intervention after setup.

The daemon focuses on a small number of core tasks: accept input, append it to the current log file, and rotate files when certain conditions are met. Optional behaviors such as timestamping or filtering are applied during the write path, allowing the same pipeline to handle both storage and basic log presentation.

2.1 Log input handling

Input is usually supplied through a pipe connected to the output of the service being logged. svlogd reads incoming text as it arrives, treating each line or record as part of a stream rather than as isolated events. This makes it suitable for programs that emit plain text diagnostics, status messages, or audit-style entries.

The daemon does not generally interpret log content semantically. Instead, it handles the stream in a transport-like manner, preserving the order of messages and passing them through any configured transformations before writing them out. This keeps processing overhead low and makes the tool predictable.

2.2 Output file writing

Written log data is appended to the active log file in the service’s log directory. svlogd keeps the current file open for ongoing writes, which allows it to accumulate entries efficiently without repeatedly creating new files.

The output path is typically managed in a way that supports safe rotation and orderly archival. When a file reaches the configured limit or another rotation rule is triggered, svlogd closes the active file and begins a new one. This provides a straightforward balance between continuous capture and file manageability.

2.3 Rotation behavior

Rotation is one of svlogd’s primary responsibilities. The daemon maintains a current log file and moves older material aside according to the configured rules. Rotation keeps individual files from becoming excessively large and makes browsing or archiving logs easier.

The exact behavior depends on settings that govern file size, the number of files retained, and optional annotations. These controls let administrators define how long logs remain available and how they should be organized over time.

2.3.1 Size-based rotation

A common trigger for rotation is file size. When the active log reaches a specified threshold, svlogd closes it and starts a fresh file. This approach prevents any single file from growing without bound and makes log review more convenient.

Size-based rotation is especially useful for busy services with steady output. It gives administrators a simple way to anticipate disk use and to ensure that recent records remain in a manageable file even when logging volume is high.

2.3.2 Maximum file count handling

svlogd can also be configured to keep only a limited number of rotated files. When that limit is exceeded, older files are removed or otherwise retired according to the program’s retention rules.

This cap helps control storage consumption while still preserving a useful history of recent activity. It is a practical safeguard on systems with limited disk space, and it reduces the need for manual cleanup of old archives.

2.3.3 Timestamping rotated logs

Rotated logs may be marked with time information so that each file reflects when it was created or closed. Timestamping helps establish a chronological sequence and simplifies later analysis.

This feature is useful when multiple rotations occur over a short period or when administrators need to correlate log files with external events. The resulting filenames or annotations provide a compact record of file age without requiring separate metadata.

3 Configuration

svlogd is configured primarily through files and directory layout, with optional command-line arguments and environment settings providing additional control. The configuration style follows the broader daemontools preference for simple, readable inputs that can be edited directly.

Most behavior is determined by the presence of specific control files in the log directory. These files allow service-specific tuning without requiring a centralized configuration database. As a result, different services can use different logging policies while still relying on the same daemon.

3.1 Configuration files and directories

The logging setup usually centers on a dedicated directory associated with the service. Inside that directory, svlogd looks for control files that define rotation limits, formatting preferences, and other local rules.

This directory-based approach is easy to replicate across many services. Administrators can create a standard structure for each log service and then adjust only the small set of files needed for that service’s behavior. The result is both consistent and flexible.

3.2 Environment and command-line options

svlogd can also respond to options supplied at startup. These arguments may specify behavior such as file size thresholds, rotation counts, or message formatting rules. Environment variables may likewise influence execution in some deployments, especially when invoked by scripts or supervision wrappers.

These controls are generally supplementary to the directory-based configuration. They are useful when a service needs a temporary override, a custom startup parameter, or a deployment-specific adjustment that should not be embedded permanently in the log directory itself.

3.3 Per-service log settings

Per-service settings allow each supervised program to maintain its own logging policy. A quiet daemon may keep many small files for long-term history, while a chatty process may use larger thresholds and stricter retention. This separation avoids one-size-fits-all assumptions.

The settings are usually maintained alongside the service’s log directory, which makes the logging policy easy to locate and audit. Because the configuration is local to each service, changes can be made without affecting unrelated processes.

3.3.1 Naming conventions

Log files and control files often follow a naming pattern established by the logging setup. The convention helps svlogd identify which files are active, which are rotated, and which settings apply to the current directory.

Clear naming also assists human operators. When filenames encode sequence or time information, it becomes easier to inspect the log history, determine the newest file, and understand how the rotation scheme is working.

3.3.2 Log directory structure

The log directory commonly contains the current log file, rotated archives, and any control files used by svlogd. In a service supervision tree, this directory is usually separate from the application’s data directories, which keeps logging responsibilities isolated.

A typical structure supports both automation and manual review. Scripts can rely on the directory’s layout, while administrators can enter it directly to inspect recent output or adjust configuration files. This simplicity is one of the hallmarks of the tool.

4 Features

svlogd combines a small feature set with a focused operational model. Its capabilities are not extensive in the sense of a centralized log platform, but they are sufficient for many service-oriented systems that need dependable local logging.

The feature set is oriented toward continuous capture, manageable rotation, and light post-processing. In practice, this gives operators a practical balance between automation and control without introducing unnecessary complexity.

4.1 Continuous log capture

A central feature of svlogd is uninterrupted receipt of service output. As long as the supervised program emits data, the logger continues to accept and store it.

This continuous capture model is particularly useful for daemons that run for long periods and produce sporadic or high-volume messages. It avoids manual intervention and ensures that records are preserved as part of normal service operation.

4.2 Automated log rotation

Automatic rotation is one of the main reasons administrators choose svlogd. The daemon monitors the active log and starts a new file when rotation conditions are met, reducing the need for cron jobs or external scripts.

Automation lowers operational burden and improves consistency. Since rotation is handled by the logging process itself, the risk of missed cleanup intervals or duplicate handling is reduced.

4.3 Filtering and formatting

svlogd supports limited transformations that can modify how entries are written. These may include simple filtering rules or formatting adjustments applied before output is stored.

Such processing is usually lightweight and intended for practical refinement rather than complex parsing. It can help suppress unwanted messages, make output more readable, or adapt records to a preferred local style.

4.4 Date and time annotation

The daemon can annotate log output with date and time information, improving readability and traceability. This is helpful when services emit plain text that lacks its own timestamps.

Annotations make it easier to align logs with external events, identify periods of activity, and compare one service’s output with another’s. They are especially valuable in environments where logs are reviewed directly from files rather than forwarded into a larger logging system.

4.5 Integration with service supervision

svlogd is designed to work closely with service supervisors. Its most common deployment pattern is as part of a managed service directory, where the application and its logger are both supervised.

This integration provides orderly startup and shutdown behavior, clearer separation of duties, and a consistent administrative model. The logger becomes one component in a controlled service tree rather than a separate, manually managed background job.

5 Usage patterns

In practice, svlogd is used as part of a service’s logging pipeline rather than as a standalone utility. Administrators typically create a log service, connect it to the main service, and let the supervisor keep both running.

The resulting workflow is straightforward: logs are collected automatically, rotated according to policy, and checked as needed by the operator. This approach is valued for its low maintenance requirements and transparent structure.

5.1 Setting up a log service

A common setup begins with creating a dedicated log directory and linking it to the service being supervised. The logger is then started as a companion process, often under the same supervision framework that controls the main daemon.

Once connected, svlogd reads the service’s output and begins writing to log files immediately. Administrators may then add rotation settings or formatting rules by placing control files in the directory.

5.2 Managing service logs

Day-to-day log management usually consists of reviewing current files, checking rotated archives, and adjusting retention or size limits as needed. Because the log structure is local and conventional, these tasks are often done with standard Unix tools.

When troubleshooting, operators may inspect the most recent file first, then examine older rotated logs to reconstruct a sequence of events. The predictable naming and rotation scheme makes this process efficient.

5.3 Common administration workflows

Typical workflows include provisioning a new service with logging already in place, cloning a known-good log configuration to another service, and fine-tuning rotation after observing actual message volume.

Administrators may also use svlogd in scripted deployments where a service template creates both the application directory and its logging companion. This makes it easy to deploy many similar services while preserving individual log histories.

6 Implementation details

svlogd is built around a simple process model and relies on standard Unix mechanisms for stream handling. Its implementation reflects the broader design goals of daemontools: small components, clear responsibilities, and minimal dependence on heavyweight infrastructure.

The program’s internal structure is oriented toward reading from a pipe, writing to files, and reacting cleanly to changes in state. This makes it robust in environments where processes are started, stopped, or rotated under supervision.

6.1 Process model

The logger generally runs as a long-lived process dedicated to one service’s output stream. It remains active for the duration of the service, continuously consuming input and maintaining the current log file.

This one-process-per-stream pattern is simple and effective. It avoids multiplexing complexity and reduces the number of moving parts involved in log handling.

6.2 Interaction with pipes and file descriptors

svlogd typically receives data through standard Unix pipes connected to the producing service. It reads from one file descriptor and writes to another, allowing the logging path to remain compact and direct.

This file-descriptor-based design is a natural fit for daemontools, which relies heavily on controlled process wiring. It also makes the logger easy to combine with other command-line tools that produce or transform text streams.

6.3 Signal handling

Because svlogd runs under supervision, it must respond cleanly to process control signals. These signals may indicate that it should flush data, close files, rotate output, or exit under the supervisor’s direction.

Predictable signal handling is important for preserving log integrity. By reacting gracefully to termination or rotation events, the daemon reduces the chance of partial writes and helps ensure that files remain in a consistent state.

svlogd is part of a family of utilities associated with Unix service supervision and compact logging. Its design is easiest to understand in relation to other daemontools components and similar logging programs.

These tools share a preference for small, composable behavior. While they differ in exact purpose, together they illustrate a style of administration that values simplicity, scriptability, and clear process boundaries.

7.1 daemontools

daemontools is the broader suite from which svlogd comes. It provides supervision mechanisms for services and encourages a directory-based model for managing long-running processes.

Within that framework, svlogd functions as the logging counterpart to service supervision. The suite’s overall design helps coordinate startup, monitoring, and log capture in a unified way.

7.2 multilog

multilog is another logging utility in the same ecosystem. It is often mentioned alongside svlogd because both handle service logs in a supervised environment and support rotation-oriented workflows.

The two programs are closely related in purpose, though they may differ in configuration style and features. Their shared goal is to provide reliable, lightweight logging without depending on large external systems.

7.3 supervise

supervise is the daemontools component that monitors services and restarts them if needed. It is commonly paired with logging tools so that both the application and its log pipeline remain under supervision.

In a typical setup, supervise manages the main daemon while a logging process handles the output stream. This pairing creates a stable service arrangement with clear operational responsibilities.

7.4 Other Unix logging utilities

Other Unix logging tools include file rotators, stream collectors, and system logging daemons. Some are general-purpose, while others are tailored to specific environments or configuration styles.

svlogd differs from many of these in its strong association with supervised service directories and its emphasis on simple local file handling. Its place among Unix logging utilities is defined by that compact, service-centered approach.