[systemd-devel] Non-target, dependency-only unit

Lennart Poettering lennart at poettering.net
Fri Jan 20 19:26:08 PST 2012


On Mon, 16.01.12 15:00, Pablo Nehab Hess (pablo at hess.net.br) wrote:

> I'm trying to convert Spacewalk's init script to a systemd unit file.
> 
> Spacewalk is merely a collection of dependencies; it depends on
> {httpd,tomcat6,postgresql}.service and a few others, but there's no
> proper daemon or any such thing. The original init script lives at
> '/usr/sbin/spacewalk-service' and simply performs 'start' or 'stop' or
> 'restart'/'reload' for all those dependencies in a specific order.
> 
> If the only desirable action was 'start', then a target unit would be just fine.
> 
> However, the administrator must be able to at the very least 'stop'
> and 'reload'/'restart' it.
> 
> The solution I've been using is inserting all but the last dependency
> into 'ExecStartPre' and 'ExecStopPost' directives, but does *not* look
> correct to me.
> 
> Is there any other solution I'm unaware of?

Hmm, interesting problem.

here's a solution that should work. Create spacewalk.target as unit file
which pulls in all services in question (via Requires= and orders itself
before them), and then place in its [Install] section something like the 
following:

Alias=postgresql.service.requires/spacewalk.target httpd.service.requires/spacewalk.target tomcat6.service.requires/spacewalk.target

That means that by running "systemctl enable spacewalk.target" these
services will suddenly be depending on spacewalk (thus ultimately having
requires deps in both directions), and when you stop the spacewalk
target they will be stopped too, and when you restart the spacewalk
target they will be restarted, too.

At least in theory that should do the job and have quite nice user
experience.

This leaves only one thing open: that reloads are forwarded from
spacewalk to the individual services. For that systemd v38 recently
gained the PropagateReloadTo= feature, which allows you to link the
reload of one unit to another one. See systemd.unit(5) for more
information.

Does that make some sense?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the systemd-devel mailing list