# Interfaces that are new

nosh incorporates several interfaces and mechanisms that might be new to you:

## Bundle directories

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`.)

Full documentation can be found at the `service-bundle` manual page.

## Distinct managers

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.)

## Distinct scanners

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.

## Standard targets

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.