1

I wrote an LSB init script that can manage multiple instances of my daemon: rcfoo start starts all the instances (which are found in some /etc configuration file), rcfoo stop stops all the instances, rcfoo status displays the status of all instances, and rcfoo reload reloads updates the daemon with a changed configuration.

First I wonder how to detect the instances to work on with some foo@.service systemd unit file. AFAIK I must specify all the instances like foo@A, foo@B, and so on.

Second my LSB script can report an extended status, meaning it can display whether a service reload is needed (and my reload actually optimizes to only reload the services that need it). How can I make a custom status report? I think a script has to use systemd-notify for custom status messages.

Fortunately my final extension to the LSB script, namely manipulating single instances by adding single <instance> (like in rcfoo start single A), is supported out-of-the-box with systemd.

So my basic question is the first one.

0

I found two possible solutions:

  1. Write a "wrapper script" that accepts an instance parameter and a command parameter. Then the script has to search whether the instance requested is actually found in the configuration file in /etc. The script actually does provide start, stop, and reload, while the PID of the daemon process is handled by systemd via PIDFile=.

    In addition write a service unit like foo@.service that contains the wrapper script for ExecStart=, ExecStop=, etc. The instance name is represented by %i there. What's not so nice is the fact that you'll have to know the instance names, and when using an invalid one, systemd creates a non-operational instance that is repeatedly restarting (until cleaned up manually with systemctl reset-failed). The thing with conditional restart wasn't solved with this approach. So you would systemctl start foo@A.

  2. Alternatively you can get rid of the wrapper script by writing a generator reads the configuration file and creates a service instance unit file for each instance found. The command-lines being used is assembled by the generator using the config file. Additional shell commands (e.g. to create a runtime-directory, or to wait for daemon fork to complete) are added by the generator via ExecStartPre= and ExecStartPost=.

    There are some issues unresolved, but the systemd community represented on the development list wasn't actually helpful: They told me generators are an advanced concept that I should not use it, not actually answering my questions.

Things missing in this answer are: How to configure a sytemd target that starts and stops all services? I thought I'd have one, but it failed on boot (generated unit file was empty for unknown reasons).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.