Archnosh is nosh for Archlinux
This repository provides the build files necessary to integrate the nosh system and service manager with Archlinux package management.
The packaging here closely follows the Debian packaging provided by the author of nosh.
How do I use it?
With caution! Installing some of the nosh packages provided here can profoundly change the way your system bootstraps and runs services.
Furthermore, the packages have so far been tested locally on virtual machines with minimum installs of early 2018 Archlinux releases and on a personal laptop, where they do work for the most part but tailoring to your system will be necessary.
This is a split-package PKGBUILD which will generate packages covering the toolset aswell as a service bundle collection which together can provide a complete working system.
Use the latest available released archive, i.e. the latest tagged git commit.
This README applies to the latest release.
Note that preset files will be handled as config files.
Service bundles, however, are a form of configuration via the filesystem and are less amenable to pacman's config file mechanism. Saving the run files under the
service directory would reflect this configuration only partially. Currently therefore, in order to preserve customization through package upgrades, you should patch the systemd-like service files from which the bundles are generated.
The make dependencies are the following and require AUR access to be set up:
Build and install the packages
Put the files in a directory and run:
You can then install the generated packages with:
# pacman -U <package-name>
N.B.: due to a change in dbus-daemon behaviour and since nosh-1.37, the
nosh-service-management package needs to override the
dbus-daemon-launch-helper binary from the
core/dbus Archlinux package with its own. While the Debian package uses the
dpkg-divert mechanism, no similar method appears to exist on Arch (suggestions welcome).
The Archnosh package currently overwrites
/usr/lib/dbus-1.0/dbus-daemon-launch-helper. This has two consequences:
- one must use the
--forceoption when installing with pacman to avoid a file collision error
nosh-service-managementnow competes with
core/dbusand must be reinstalled when the latter is updated.
Read the timorous admin's installation how-to.
The following describes the two expected common setups.
Both assume that you are running the default systemd-managed install.
nosh service manager only: nosh-run-via-systemd
It is possible to run nosh as a service manager alongside systemd.
The following packages are necessary:
- nosh-run-debian-server-base or nosh-run-debian-desktop-base
Due to Archlinux's default preset disable policy (
/usr/lib/systemd/system-preset/99-default.preset), you need to enable the following unit:
# systemctl enable service-manager.socket
Then you should enable one or both of:
system-control-normal.service uses nosh targets to bring up enabled services. Simply run
system-control enable <service> and
systemctl disable <service> for its equivalent in order to switch management of the service over to nosh.
service-manager-svscan.path will scan and bring up any service bundle you place in the
/service directory (which you will have to create), effectively enabling it. This is the more typical daemontools approach.
It's probably simpler to stick to just one of these methods.
Creating preset files for these units will also ensure their enabled/disabled status in case of package upgrades.
Also make sure to check the presets provided by the chosen
nosh-run-debian-X-base package, they will activate some services by default.
nosh system and service manager: nosh-run-system-manager
For a fully nosh-managed system, i.e. nosh running as the init process and service manager, install the following packages:
- nosh-run-udev or nosh-run-systemd-udev
- nosh-run-debian-server-base or nosh-run-debian-desktop-base
Installing these packages will raise a lot of the following errors:
reset: ERROR: connect: /run/service-manager/control: No such file or directory
This is due to the fact that nosh isn't actually properly running yet but is not an issue. The system will work properly after a reboot (
The installation above assumes udev is the device manager, which is provided by the systemd package on Archlinux.
The easiest method is to simply use the binaries and configuration files provided by this package to run udev. The
nosh-run-systemd-udev package will do just that and everything should work transparently. This means all udev configuration rules already set up should work as-is.
Alternatively you may wish to use the eudev implementation rather than keeping the systemd package for udev functionality.
This conflicts with the libsystemd package, you should remove it but it will almost certainly be a dependency for other packages on your system so run:
# pacman -dd -S libeudev
--nodeps) repeated option skips dependency checking. You will be providing replacements for these dependencies.
It might also fail to install due to the following pre-existing files:
/usr/lib/pkgconfig/libudev.pc. Remove these manually.
This will provide the
This conflicts with the systemd package and, again, will doubtless bring up many dependency warnings so run:
# pacman -dd -S eudev
This will provide some shim systemd binaries and libraries.
nosh-run-udev package will run the
udevd binary, provided by eudev here.
From there you will have a working udev and some systemd shims which should allow installing most packages without too much trouble.
Run-packages for other device managers are provided: vdev, busybox-mdev and suckless-mdev. You will probably need to account for Archlinux's rather heavy systemd/udev integration in order to use them.
nosh-run-debian-X-base packages have not currently been renamed but one of them must be used.
They provide essential presets for booting your system. The "desktop-base" extends the "server-base" presets.
Make sure to check, modify or add preset files where necessary in
90-*-boot-essentials.preset files, in particular, contain services for mounting filesystems, for loading necessary kernel modules, service targets to achieve etc.
per-user service management
For user-controlled services, a per-user manager can be enabled for user my_user with:
# system-control enable user@my_user
This will start per-user service management for my_user on system boot.
User service bundles can be placed under
$HOME/.config/service-bundles/services/ and controlled with:
$ system-control --user <command>
Service bundles are available for various network managers, such as Wicd and NetworkManager.
Native network configuration is also available.
dhcpcd@ service (the default enabled tool for wired devices on Archlinux) is generated for each interface and is preset enabled by
It should be enabled automatically (on interfaces configured with dhcp of course). The discovery script will detect dhclient, udhcpc and dhcpcd. You can manually set your client in
/etc/rc.conf.local with the
For interfaces managed by
ifconfig@ scripts, the net-tools package needs to be installed to provide the
Don't forget to run
redo all after applying configuration changes. Check
/etc/system-control/convert/static-networking to make sure the desired services for your interface are set to
non-root Xorg and device access
Since we are not using systemd's
logind, starting X as an unpriviledged user requires adding that user to the "input" and "video" groups.
See https://wiki.gentoo.org/wiki/Non_root_Xorg for further details.
In the same vein, other device access may no longer work for unpriviledged users. You will probably have to add users to the "audio" group to use a soundcard for instance.
elogind might conceivably be used to achieve systemd behaviour here.
Various "shim" packages exist to provide the following:
Commands from other service or system managers that will invoke the corresponding nosh management actions, e.g. nosh-debian-shims, nosh-systemd-shims, nosh-upstart-shims, etc.
Utilities which may be provided by other packages, e.g. nosh-execline-shims, nosh-ucspi-tcp-shims, nosh-kbd-shims, etc.
Rather than kernel virtual terminals, user-space virtual terminals may be used by installing
nosh-execline-shims package is necessary if you do not have execline available.
troubleshooting and exceptional boot modes
In certain cases your system may need to be booted in an exceptional mode.
A rescue mode is available for nosh by appending "s" to the kernel boot parameters.
An emergency mode is available by appending "b" to the kernel boot parameters.
Some nosh guidelines
The nosh toolset follows general daemontools design which includes:
- using the filesystem as database and API: the system can be inspected and modified using standard filesystem commands
- logging as an ordinary --"first-class citizen"-- service
- chain-loading of simple utilities to build a controlled final running state
- composability: utilities from other toolsets in this family can be used in conjunction with nosh
To these features nosh adds:
- explicit separation of service and system management
- terminal management
- service ordering and interdependency through "service bundles" which allows for system "targets" similar to systemd
- restart scripts
For a general presentation you may read the following:
A standard bundle will look something like this:
/var/sv $ tree kamailio kamailio ├── after │ ├── basic -> /etc/service-bundles/targets/basic │ └── log -> ../log ├── before │ └── shutdown -> /etc/service-bundles/targets/shutdown ├── conflicts ├── log -> ../cyclog@kamailio ├── required-by ├── service │ ├── env │ ├── restart │ ├── run │ ├── start │ └── stop ├── stopped-by │ └── shutdown -> /etc/service-bundles/targets/shutdown ├── supervise │ ├── control │ ├── lock │ ├── ok │ └── status ├── wanted-by │ └── server -> /etc/service-bundles/targets/server └── wants └── basic -> /etc/service-bundles/targets/basic
after directories allow for linking to other service bundles to set ordering constraints.
wants directories allow for linking to other service bundles to set dependency constraints.
log directory points to a logging service.
service directory contains the scripts used to run the service.
service/env can be used to store configuration information.
supervise directory contains the control/status API files.
Logging is a service on par with any other. In general one logging service is associated with each daemon to capture and manage its output (log rotation, size capping etc.) although fan-in from multiple services to one logging service is also possible.
The daemontools assumption is that daemons log to their standard error, not to syslog. Specialised logging tools can then be used to manage this output.
More generally, daemons are expected not to implement functions such as dropping privileges, socket management, resource limiting, etc. which could be provided by external tools, typically the daemontools family toolsets and other service managers (see the same argument for systemd's "new-style" daemons).
In practice, nosh connects a service's standard output and error to the service pointed to by the "log" directory of the service bundle. Below are some excerpts of the
lsof command to illustrate:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME # the sshd service, file descriptors 1 and 2 refer to pipe 17119 tcp-socke 976 root cwd DIR 254,0 4096 198091 /var/sv/sshd/service tcp-socke 976 root txt REG 254,0 212968 62095 /usr/bin/tcp-socket-accept tcp-socke 976 root 0r FIFO 0,10 0t0 17188 pipe tcp-socke 976 root 1w FIFO 0,10 0t0 17119 pipe tcp-socke 976 root 2w FIFO 0,10 0t0 17119 pipe # the cyclog@sshd service, file descriptor 0 refers to pipe 17119: reading sshd's stdout and stderr cyclog 963 sshd-log txt REG 254,0 212968 63713 /usr/bin/cyclog cyclog 963 sshd-log 0r FIFO 0,10 0t0 17119 pipe cyclog 963 sshd-log 1w FIFO 0,10 0t0 8409 pipe cyclog 963 sshd-log 2w FIFO 0,10 0t0 8409 pipe cyclog 963 sshd-log 6w REG 254,0 0 202749 /var/log/sv/sshd/current # note that cyclog@sshd's own stdout and stderr point to pipe 8409 which is actually the system-wide logger's input cyclog 163 root txt REG 254,0 130984 63711 /usr/bin/system-manager cyclog 163 root 0r FIFO 0,10 0t0 8409 pipe cyclog 163 root 1u CHR 5,1 0t0 6547 /dev/console (deleted) cyclog 163 root 2u CHR 5,1 0t0 6547 /dev/console (deleted) cyclog 163 root 5w REG 0,18 81718 8433 /run/system-manager/log/current # ... just as init's own stdout and stderr also point to the system-wide cyclog init 1 root txt REG 254,0 130984 63711 /usr/bin/system-manager init 1 root 0r CHR 1,3 0t0 6465 /dev/null init 1 root 1w FIFO 0,10 0t0 8409 pipe init 1 root 2w FIFO 0,10 0t0 8409 pipe
The "log" directory name is a bit misleading insofar as one could chain anything to the service and create an arbitrarily long pipe chain. That being said, service
run files already use chain-loading mechanisms so it generally really is a logging service that is ultimately piped to.
system-control is the system workhorse command from a user perspective.
It provides high-level system-wide and per-user service management (start/stop, enable/disable etc.) aswell as system management (reboot, poweroff etc.) and various other specialised commands for e.g. converting systemd-style unit files to service bundles.
Converting systemd unit files
system-control convert-systemd-units <unit-file> supports conversion for various types of systemd unit files to service bundles.
It also understands extended syntax to express service bundle-specific functionality in a systemd-like unit file, which can be used for easy distribution for example.
In other words, one can benefit from existing systemd unit files through automatic conversion in many cases.
Basic support for service management is available with the Ansible nosh module.
This repository is publicly available at the following locations:
These packaging configuration files are distributed under the public domain Unlicense, see the UNLICENSE file provided.
The nosh software, however, is distributed under BSD/BSD-compatible licensing.