# Interfaces that you are used to

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.