nosh uses several interfaces that you might already be familiar with:
The fundamental service management mechanism is taken from daemontools, with some augmentations from daemontools-encore and some ideas from runit, perp, and s6.
A dæmon is run using a run program (usually a script) in a service directory.
In addition to the standard daemontools run program, there are start, restart, and stop programs.
Several of the tools have daemontools-compatible modes and names.
service-control can be used under the name svc, and supports the short options -u, -d, and so forth.
service-dt-scanner can be used under the name svscan.
service-status can be used under the name svstat.
service-is-ok can be used under the name svok.
The control/status API is a supervise directory, containing ok, status, control, and lock.
The status file incorporates the
daemontools-encore extensions that report more detailed service state information.
svc has been enhanced with the additional signal capabilities from
runit,
daemontools-encore, and
s6.
svc -w sends a SIGWINCH signal, for example.
The service and system management mechanism is intentionally similar to systemd.
The standard target bundles have familiar names: "multi-user", "local-fs", "remote-fs", "sysinit", and so forth. There are some differences in the details ("multi-user" is a sub-target, not a main target, for example) but the gist is the same (The "local-fs" target is mostly what a system administrator used to systemd or the LSB might expect it to be, for example.)
The system-control utility can be used under the name systemctl, and supports some of the subcommands from systemd's command of the same name: enable, disable, preset, start, stop, status, show, reboot, poweroff, and so forth.
The command to enable a service is still systemctl enable name.
The command to poweroff the system is still systemctl poweroff.
The service management mechanism shares systemd's notion of services that are "enabled" so that they are activated automatically at (normal) bootup.
An extended set of systemd signals (SIGRTMIN + n) is made available on BSD, in addition to the small set of conventional BSD signals.
Familiar mechanisms such as /etc/machine-id and /etc/hostname, and their associated boot-time initialization services, are available.
The system management control mechanism and toolset are similar to BSD's and Linux's old System V mechanism and toolset, and have compatibility mechanisms.
One sends signals to process #1 to change system states.
The service, rcctl, chkconfig, halt, poweroff, reboot, and telinit tools provide a compatibility subset of the BSD and Linux System V tools of the same names.
The command to enable a service is still rcctl enable name.
The scripting utilities parallel daemontools, s6, and daemontools-encore.
All of the daemontools chain-loading commands are available: envdir, envuidgid, setlock, setuidgid, and softlimit.
pgrphack is replaced by setsid and setpgrp.
multilog is replaced by cyclog (which was in fact the logging command in older versions of daemontools).
Socket utilities use the UCSPI-TCP, UCSPI-UDP, and UCSPI-LOCAL conventions.
Socket utilities can also use systemd's LISTEN_FDS convention.
And, of course, one can import many systemd service and socket unit files to the native service bundle form very easily.