nosh incorporates several interfaces and mechanisms that might be new to you:
Service and supervise directories are stored as two (of several) subdirectories of an over all service bundle directory. Other subdirectories contain symbolic links that define service interrelationships and orderings.
Bundle directories can live anywhere that one likes in the filesystem.
The system-control program locates various standard targets in the /etc/service-bundles/targets directory.
But those targets refer to other services (and targets) via symbolic links, which can point anywhere in the filesystem.
(A slight restriction on this is also the fairly obvious one:
Bundles for services and targets that are started in parallel with, or before, mounting the non-root filesystems must live on the root filesystem.
By convention, these "sysinit" bundles live in /etc/service-bundles/services.
Since their supervise directories must be writable at run-time, they are symbolic links to directories that live under /run/service-bundles/early-supervise.)
The service manager is not the system manager.
The service manager (service-manager) manages dæmons, and their state transitions through the "stopped", "starting", "running", "failed", and "stopping" states.
The system manager (system-manager) manages the state machine for the system as a whole, with the "normal", "rescue", and "emergency" bootstrap modes, the "halt", "reboot", and "poweroff" targets, and system-level control mechanisms such as hotkeys (Control+Alt+Delete and on Linux Alt-UpArrow) on the system console.
(Those familiar with Windows NT and ReactOS can see the system manager as akin to SMSS (the Session Manager Subsystem) which runs as process #1 and manages startup and shutdown, and the service manager as akin to SERVICES (the Service Controller) which manages service processes and provides an RPC API.
They are quite different when compared in detail, though.
Those familiar with IBM AIX can see the system manager as akin to init and the service manager as akin to srcmstr.
Similarly, those familiar with Solaris can see the system manager as akin to init and the service manager as akin to svc.startd.
Again, there are differences in the details.)
The service manager is not the service scanner.
In daemontools (and in
s6 and
daemontools-encore) the service scanner forks supervisory processes for services, directly.
In this system the daemontools-compatibility service scanner, service-dt-scanner, talks through the RPC API to the service manager, which forks the service processes.
The service scanner is not the parent of service processes.
Indeed, it can be treated as a service itself (running under the service manager), and can be brought up and down.
Traditional daemontools service scanners are not expected to be terminated, in contrast.
One can do away with service-dt-scanner and any /service/ directory entirely, moreover.
The service manager API provides mechanism; whereas tools like service-dt-scanner determine in what particular way that mechanism is used, and are replaceable.
Running system-manager as process #1, there's no daemontools-compatible scanner involved in normal operation.
Instead, system-control institutes the full service/target bundle interdependency framework.
restart scripts
Whenever the last service process for a service that is in the "running" state finishes, the service manager runs the service's restart program.
(Some services, particularly targets, can be specially marked as "run on empty", which alters this behaviour.)
This program is given arguments that tell it the status of the last service process: whether it exited, crashed, aborted, was terminated, or was killed; and what the signal or exit code was.
A very simple restart script executes the true command, which causes the service to be unconditionally restarted by the service manager.
However, one can do a lot more than that.
More complex restart scripts can …
… decide whether to restart or to stop dependent from how the process terminated;
… generate alert messages to monitoring systems;
… delay restarting services by pausing for some timeout interval;
… perform service-specific cleanup/reset actions.
This package has more standard targets than systemd, taking notions of distinct "multi-user" and "server" from the Solaris SMF milestones system:
Services that are part of running a workstation, as opposed to a server, machine are enabled by being added to the "wants" list of the standard "workstation" target.
Services that are part of running a server, as opposed to a workstation, machine are enabled by being added to the "wants" list of the standard "server" target.
Services that are part of providing multi-user login are enabled by being added to the "wants" list of the standard "multi-user" target.
It has different standard targets to systemd:
The default target is named "normal", not "default". "normal" encompasses "server", "workstation", "multi-user", "static-networking", and "users".
It also has fewer standard targets than systemd:
There are no "runlevel" targets. There is no concept of run-levels, full stop.