Creating bundles

If you are unlucky enough to have a package that does not supply service bundle directories for its services, you have some options.

You can build a bundle using parts from some public run script collections.

Gerrit Pape made a collection of some run scripts some years ago. Wayne Marshall has collected a few more. So has Kevin J. DeGraaf. And so has Glenn Strauss. Simply take an appropriate run script, add minimal start, stop, and restart programs, put the lot into a service directory, put that into a bundle directory, and enable/start the service.

Minimal start, stop, and restart scripts are simply:

#!/bin/nosh
true

Note: Gerrit Pape's and Wayne Marshall's collections use shells as the script interpreters. Several of the scripts can be simplified yet further with use of nosh and its built-in toolset. One can replace uses of tools such as chpst and tcpsvd with the equivalent daemontools-alike tool(s) and some combination of tcp-socket-listen, tcp-socket-accept, and ucspi-socket-rules-check.

However, it is not compulsory to change such run scripts if one has the various relevant tools available. Service management places no restrictions upon how a run program is actually implemented. run programs just need to be executable, and can after all be written in many ways: in Perl, as shell scripts, as nosh scripts, as execlineb scripts, in Python, or even in compiled languages.

You can import a systemd service unit file.

If the package comes with a systemd service unit file (and potentially an accompanying socket unit file), you can import it. Simply run system-control convert-systemd-units servicename and the import utility will attempt to import the service and write a bundle directory. (You can control where the bundle directory is written.) This can cope with many systemd service units, as long as they aren't Linux-specific, esoteric, or too clever by half.

The import utility will display warnings about anything that it didn't understand or ignored.

You can simply write a bundle.

As mentioned above, minimal start, stop, and restart scripts are very simple. So, too, are run scripts.

The service interdependencies and orderings are usually quite simple, too:

mkdir -p wants after before stopped-by wanted-by
ln -s /etc/service-bundles/targets/basic after/
ln -s /etc/service-bundles/targets/basic wants/
ln -s /etc/service-bundles/targets/shutdown before/
ln -s /etc/service-bundles/targets/shutdown stopped-by/
ln -s /etc/service-bundles/targets/workstation wanted-by/

Tailor this according to need, of course.