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.