The nosh package

Download source: Download Debian binary packages: Download pre-built service bundle directories (shipped as Debian packages merely for convenience, and usable on PC-BSD, FreeBSD, and other operating systems): Download service units for running nosh service management under systemd (again shipped as Debian packages merely for convenience):

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

It is originally intended for use on BSDs, and to fill the gaps where BSD users, Hurd users, and others don't have the option, for whatever reason, of launchd, systemd, or upstart, and want more than what other daemontools-family systems provide, including inter-service dependencies, LSB-like/Solaris-like boot targets/milestones, and a migration path from systemd units for things coming from the GNU/Linux world.

It is known to build, run, and work on PC-BSD 9.1 and Debian Linux version 7. It should similarly build, run, and work on any modern BSD and on any modern Linux flavour. It makes use of various …at() system calls from POSIX.1:2008, for security and safety. It also makes use of the kqueue mechanism (throughout on BSD, on Linux where library bugs don't make it unusable). It might similarly build, run, and work on Hurd (although Debian Hurd has proven to be so broken in even basic things like the Debian installer that it has as yet not been possible to upload it to and compile it on a Hurd system).

It should also be suitable for filling the gap caused by the systemd tool not being portable outwith the Linux kernel since it is known to work on proper BSD and on Debian Linux, and therefore should work on Debian kFreeBSD.

You can see a real-world worked example of using the package if you like.


Its fundamental daemon management mechanism is a superset of Bernstein's daemontools mechanism. If you are familiar with Bruce Guenter's daemontools-encore you may recognize some of the augmentations, although some are new and unique to nosh and not everything is done the daemontools-encore way. This fundamental daemon management mechanism is shared across quite a number of toolsets. In addition to the aforementioned, it is largely compatible with Gerrit Pape's runit and Laurent Bercot's s6, and more roughly compatible with Wayne Marshall's perp.

Built around that is a full service and system management mechanism, with parallelized service startup/shutdown, service interdependencies and startup/shutdown orderings, and an extensible system target mechanism. In support of it, the package comes with an extensive suite of tools for creating common run scripts.

Also supplied are various system service programs for specific services. As well as various specialized programs for system initialization tasks, these include a log daemon, tools for listening to and accepting connections from TCP and local domain sockets (for socket-activity-spawned services), and tools for pseudo-terminal and virtual terminal management.

socket services

The socket mechanism is compatible with services that work with Bernstein's UCSPI-TCP mechanism and the environment variables and file descriptors that it sets up, 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.

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.

pseudo-terminal and virtual terminal management

The nosh system manager has no dealings in terminals. Like with the Solaris SMF, when using the native nosh system manager terminal login sessions are simply more services, managed by the service manager.

Several tools are included for providing simple terminal services and utilities of various kinds. For examples:

daemon management

The augmentations to the daemontools mechanism include:

Several notions are retained, including:

For compatibility:

Other features:


It comprises:

Obtaining and building

You can obtain it in two ways.

Future work in progress

Please feel free to write further service bundles. The idea is to have as complete a service bundle set as we can. If you can provide and run a repository for service bundles for the world to use and to add to, I encourage you to do so.

Please join me in asking the BSDs to put clang's C++ runtime library, libc++, in the right place. Currently it lives in /usr/lib, which isn't guaranteed available at system initialization time. To make lives a lot easier, it should live in /lib, where the C runtime library does.

Some of the work for implementing user-space virtual terminals, eight years after I first did a Linux design, has begun.

OpenBSD has just changed the semantics of its /etc/rc.conf and /etc/rc.conf.local to exclude shell expansions, which makes it compatible with the conversion mechanism. However, OpenBSD uses a different naming scheme to that used by PC-BSD/FreeBSD. NetBSD has not yet made the leap to excluding shell expansions, and uses a third naming scheme of its own.

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