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.