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.