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 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-manager1 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-manager1 instead). It is not expected to be up continually for the lifetime of the system. It re-scans directory whenever kevent2 raises a NOTE_WRITE2 or a NOTE_EXTEND2 event for that 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-control1 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-manager1 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-control1 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. 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' svscan1, daemontools-encore's svscan1, and runit's runsvdir1 all wake up every 5 seconds to poll the contents of the scan directory. (s6's s6-svscan1 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-svscan1 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-manager1. service-dt-scanner simply sends control messages. Jonathan de Boyne Pollard