service-dt-scanner, svscan — daemontools compatibility service directory scanner
service-dt-scanner
[--input-activation] {directory
}
svscan
[--input-activation] {directory
}
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.
Conventionally, directory
is /service
. Every subdirectory, or symbolic link to a directory, therein 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.
For daemontools and daemontools-encore compatibility, this command is also available as svscan.
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), runit's runsvdir(1), and s6's s6-svscan(1) all wake up every 5 seconds to poll the contents of the scan directory. 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.