The nosh package

nosh pages: Related pages: Other people's stuff that might or might not be useful:

The nosh package is a suite of system-level utilities for initializing and running a BSD or Linux system, for managing daemons, for managing terminals, and for managing logging.

For the BSD user

It is originally intended for use on BSDs, and to fill the gaps where BSD users don't have the option of launchd, systemd, or upstart, and want more than what other daemontools family systems provide. The BSD user sees:

For the Linux user

However, it can also be used by Linux users, Debian Hurd users, and others. Conversely, the Linux user sees:

Features

The features break down into dæmon management, system management, provision of socket-based services, pseudo-terminal and virtual terminal management, and log management.

dæmon management

Its fundamental dæmon management mechanism is that of the daemontools family, which is explained at that hyperlink for the unfamiliar. It comprises several of the augmentations from that family, and further augmentations that are new and unique to nosh. Augmenting that mechanism, or built on top of it, are:

Several notions are retained, including:

For compatibility:

Other features:

socket services

The socket mechanism is compatible with UCSPI services, as well as with services that use systemd's file descriptor passing protocol.

Taking a leaf out of systemd's (and inetd's) book, the package augments Bernstein's UCSPI-TCP mechanism. There are separate chain-loading programs for listening on sockets (tcp-socket-listen, local-stream-socket-listen, and local-datagram-socket-listen) and for accepting client connections (tcp-socket-accept and local-stream-socket-accept) to then spawn services in response, with configurable concurrency limits. One can use them in combination or individually. Thus listening on a socket and accepting client connections can be separated. Because of this, the package also works with services that expect the "listening" file descriptor rather than the "accepted" file descriptor, which Bernstein's UCSPI-TCP does not handle.

There is also a ucspi-socket-rules-check chain loading program for implementing socket access control for both UCSPI-TCP and UCSPI-UNIX.

system targets

The target mechanism is similar to that of systemd (and, to a lesser extent, Solaris SMF's "milestones"). The procedures of enabling, disabling, starting, and stopping services are intentionally fairly similar to those of systemd, and the standard system targets are also intentionally similar to targets in systemd.

The targets themselves have conventional well-understood names such as local-fs, poweroff, rescue, and basic.

There's an emergency target that is started if the system manager is handed the -b option; which gives an emergency superuser login prompt without attempting to mount filesystems. There's a rescue target that is started if the system manager is handed the -s option; which gives an emergency superuser login prompt after attempting to mount filesystems. The multi-user and server targets are similar to the similarly named SMF milestones.

There are no run levels.

system management

The service manager can be used subordinate to another system management mechanism, such as systemd. But the package also includes a system manager proper, separate from the service manager, that is intended to be used as process #1 of a BSD or Linux system. It handles system state including bringing the system up into its normal running state; responding to reboot, halt, and poweroff requests; bringing the system up in "rescue" and "emergency" modes; and fielding things like power notifications and a secure attention key on the system console device. It also does some of the mandatory system initialization tasks that process #1 is quietly expected to do, such as mounting "API" filesystems, creating "API" device files, and applying bodges to the system clock as early as possible.

terminal management

The nosh system manager has no dealings in terminals, which are no longer the worry of process #1. Like with the Solaris SMF, terminal login sessions are simply more services, managed by the service manager. Terminal management features include:

logging management

The nosh package includes cyclog, a simple logging dæmon that covers the commonest simple use cases and that is modelled after the program of the same name that used to come with daemontools. The log file sets that it writes are automatically rotated, timestamped, size-capped both as to total size and as to individual file size, and strictly size capped (in that there's no way, as there is with logrotate-managed logging, for a log file set to even temporarily exceed its size cap).

There are also tools for importing logs into nosh, turning them into streams of log data that can be pushed through to a log service. syslog-read is a UCSPI tool that can be attached to a local or a UDP datagram socket. klog-read is a UCSPI tool that can be attached to a FIFO or a local or TCP stream socket. For extensive details, see their manual pages and the "Logging" section of the nosh Guide.


© Copyright 2014 Jonathan de Boyne Pollard. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this WWW page in its original, unmodified form as long as its last modification datestamp information is preserved.