Organizing services/daemons with systems: running 100+ daemons, grouped by 3

maligree asked:

I’m new to systemd.

I have a machine that needs to run a substantial number of daemons. There are three types of daemons, call them daemon-A, daemon-B, daemon-C.

These daemons always run in “groups” of 3, with a configuration specific to those 3.

Occasionally, it would be necessary to restart or stop a whole group.

What’s the best way to explain this to systemd?

My current knowledge would make me simply create a new .service file for every daemon-A, daemon-B, daemon-C, for every configuration. I’m slightly lost when it comes to cgroups and slices, in that I sort of understand what they do, but a practical use case is still slightly beyond me.

I would need to be able to check on a particular group in a simple way.

Is this the way to go? Is there anything wrong with having such a big number of systemd-managed services?

My answer:

systemd actually has several unit configuration options which you can use to express the dependencies between these services.

In particular you will want to look at Requires=, Before=, After=, BindsTo= and PartOf=, all of which specify different ways in which a unit may be started or stopped in relation to other units. There are several other less commonly used ones, so read through the documentation carefully in case your daemons can use them.

(Because you didn’t say exactly what the dependencies between your services are, I can’t recommend which option you should use.)

Also, systemd can have instanced units, which start the same service but with a different configuration. An instanced unit has a name ending with @, and the instance is the name following the @. In the unit file, %I and %i are replaced with the instance name, which you can use to load specific configuration files. For example, in an instanced unit [email protected], you might specify:

ExecStart=/usr/bin/foo --daemon --config=/etc/foo/%i.conf

Then, to enable the foo service in a bar instance, you would say:

systemctl enable [email protected]

Which will cause the foo service to start with /etc/foo/bar.conf.

Note also that you can specify instances in the requirements as well. For instance, if [email protected] requires [email protected] of the same instance name, you can say in [email protected]:

[email protected]%i.service

View the full question and any other answers on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.