The atd service in the services collection is an example of a typical and commonly used regular service.
Its start
, stop
, and restart
programs are fairly trivial and straightforward.
They just chain to the true
command, which is effectively a no-operation for start
and stop
and which indicates in restart
that the service should always be automatically restarted should it terminate.
The meat of the service is its run
program.
% system-control cat atd start:#!/bin/nosh start:true stop:#!/bin/nosh stop:true run:#!/bin/nosh run:#Deferred execution scheduler run:atd -f restart:#!/bin/sh restart:exec true # ignore script arguments %
Here's its run
program alone:
#!/bin/nosh #Deferred execution scheduler atd -f
run
programs need not be scripts, but usually are in the daemontools world.
They are often shell scripts, but (as here) they need not be.
This run
script, like most of the script files in the pre-packed service bundles, uses nosh
as its script interpreter.
The needs of run
scripts are fairly simple, and they don't actually need the capabilities of a fully-fledged shell.
They never need the capabilities of a fully-fledged shell that has a complex interactive mode and a raft of startup scripts that are sourced.
A script interpreter for a run
script will thus generally be a tool designed for this purpose such as nosh
or Laurent Bercot's execlineb
, a script interpreter such as Python or Perl, or a lightweight shell such as the Almquist or (the lightweight, non-interactive, flavour of) the MirBSD Korn shell.
This nosh script is one of the simplest.
nosh
just directly chain loads the service program proper.
In more complex services one might include utility commands for (amongst other things) setting environment variables from configuration files (read-conf
), changing working directory (chdir
), dropping root privileges and running as a dedicated user that owns no files nor directories (setuidgid
), or redirecting standard open file descriptors (fdredir
).
An important thing to remember is that the interpreter process itself is considered to be the service by the service manager.
It must usually chain load the service program proper, as its final step.
With nosh
or execlineb
as the script interpreter, this happens as a matter of course.
With a shell program as the script interpreter, one must remember to run the service program proper with the shell's built-in exec
command.
Looking at the rest of the service bundle, one finds the standard things for a "regular" service. The service is auto-started (when enabled) by the "workstation" system target. It is stopped by the "shutdown" system target. It requires for correct operation that all services in the "basic" system target be started, before it itself is started. Its output is sent to a logger service.