service-dt-scanner 1 user commands nosh
service-dt-scanner svscan daemontools compatibility service directory scanner
`service-dt-scanner` --input-activation directory `svscan` --input-activation directory

## Description

`service-dt-scanner` repeatedly scans directory for service directories following the daemontools name and layout conventions. For each pair of service and supervise directories found, it instructs a service-manager 1 through its control socket to load the service, plumb it together with other related services, and either start it or arrange for it to be input-activated.

Unlike daemontools' and daemontools-encore's `svscan`, `service-dt-scanner` does not manage services. Indeed, it can be run as a service itself. (One can even run multiple instances of it feeding from multiple scan directories to a single service manager.) It does not handle any signals specially. It should not be used for process #1 (see system-manager 1 instead). It is not expected to be up continually for the lifetime of the system.

It re-scans directory whenever kevent 2 raises a NOTE_WRITE 2 or a NOTE_EXTEND 2 event for that directory.

### Scan directory

Every subdirectory, or symbolic link to a directory, in directory whose name does not start with a dot is a bundle directory. A subdirectory, or symbolic link to a directory, beneath each of those bundle directories that is named `log` is also a bundle directory. The parent bundle directory denotes the "main" service, whose output is fed through a pipe to the input of the "log" service. (See system-control 1 for bundle directories.)

`service-dt-scanner` tells the service manager to both load and start the "main" and "log" services; unless the --input-activation command-line option is used, in which case the "log" service is only loaded and marked to be input-activated. It tells the service manager to plumb the standard input of the "log" service to the standard output and standard error of the "main" service.

`service-dt-scanner` looks for a `down` file for each service in its service directory. If it finds one, it does not instruct service-manager 1 to start the service as soon as it has loaded it, as it would otherwise normally do. (Such services can be brought up later by using the service-control 1 command.)

Like daemontools and daemontools-encore, `service-dt-scanner` looks for the `down` file in the service directory, because it is persistent configuration information that remains across reboot rather than a transient part of the control/status API. This means that the service directory needs to be read-write when services are enabled and disabled.

## Compatibility

For daemontools and daemontools-encore compatibility, this command is also available as `svscan`.

The daemontools, daemontools-encore, and runit convention is that directory is `/service`.

`service-dt-scanner` implements a slight variation on bundle directories for compatibility. If the `service` subdirectory does not exist in a bundle directory, then the bundle directory itself is taken to be the service directory, instead.

daemontools' svscan 1, daemontools-encore's svscan 1, and runit's runsvdir 1 all wake up every 5 seconds to poll the contents of the scan directory. (s6's s6-svscan 1 used to as well, but nowadays does not do timed rescans by default.) The first three also have a hardwired limit of 1000 subdirectories, with s6-svscan 1 having a lower limit of 500 subdirectories.

`service-dt-scanner` relies upon the operating system to inform it of events, and does no periodic polling at all. It also doesn't do service management and so has no fixed-size arrays of services to be limited in the first place. Service management is the remit of service-manager 1. `service-dt-scanner` simply sends control messages.

## Author

Jonathan de Boyne Pollard