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):

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.


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 and tools for listening to and accepting connections from TCP and local domain sockets (for socket-activity-spawned 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. In addition, since listening on a socket and accepting client connections are separated it also works with services that expect the "listening" file descriptor rather than the "accepted" file descriptor.

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

The augmentations to the daemontools mechanism include:

Several notions are retained, including:

For compatibility:


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.

A few features are missing:

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