Re: Starting one service when another one starts

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Fr, 08.04.22 12:54, Nick Howitt (nick@xxxxxxxxxxxxx) wrote:

> Hi,
> I apologise if this is not the right place for user help. If it is not,
> please point me to the best place.
>
> I am trying to start a service (clearshare-scheduler) when another service
> (siad) starts. Clearshare-scheduler is an odd service. When you start it it
> may run for ages (days+) or it may terminate immediately so I have set it up
> as a oneshot:

That's not really necessary. You can set RemainAfterExit=yes to define
units if the other types which will remain in "running" state even if
all processes they define die.

>
> [Unit]
> Description=Clearshare Scheduler
> PartOf=siad.service
> After=siad.service
>
> [Service]
> Type=oneshot
> Environment="TERM=dumb"
> ExecStartPre=-/usr/bin/killall -15 -q
> /usr/sbin/clearshare-scheduler.sh

I hope this is for testing only..

> ExecStartPre=-/usr/bin/echo "$(/usr/bin/date) Starting scheduler from
> systemd" >> /var/log/scheduler.log

systemd does not implement a shell, and ">>" is shell syntax, not
systemd syntax.

> ExecStart=/usr/sbin/clearshare-scheduler.sh > /dev/null

Similar.

> ExecStop=-/usr/bin/killall -15 -q /usr/sbin/clearshare-scheduler.sh

systemd will SIGTERM everything remaining in the service's cgroup anyway...

> [Unit]
> Description=Siad
> After=syslog.target network.target clearsync.service

syslog.target is long obsolete.

>
> [Service]
> Type=simple
> OOMScoreAdjust=500
> PIDFile=/var/run/siad.pid
> EnvironmentFile=/etc/sysconfig/siad
> Environment="SIA_DATA_DIR=/var/lib/siad-data"
> ExecStartPre=-/usr/bin/killall -15 -q clearshare-scheduler.sh

As above.

> ExecStartPre=-/usr/bin/rm -f /var/run/siad.pid

systemd removes declared PID files automatically.

> ExecStart=/usr/bin/siad $EXTRA_ARGS
> ExecStop=/usr/bin/siac stop
> WorkingDirectory=/var/lib/sia/
> ExecStartPost=/usr/bin/sh -c 'umask 022; /usr/bin/pgrep siad >
> /var/run/siad.pid'
>
> [Install]
> WantedBy=multi-user.target
>
> A "systemctl show clearshare-scheduler" lists the PartOf=siad.service as one
> of its properties but, in reverse, "systemctl show siad" does not list the
> corresponding ConsistsOf property.

systemd loads units lazily, as they are referenced. Thus "systemctl
show siad" does not show the deps towards "clearshare-scheduler", then
that's because there was no reason to load the latter if you just ask
for the former.

Usually you would solve that by just adding a "Wants=" line to your unit
clearshare-scheduler.service towards siad.service.

if you want "losely couple" this, i.e. don't want to modify
"siad.ervice" in to point to "clearshare-scheduler.service", then use
"WantedBy=siad.service" in "clearshare-scheduler.service"'s [Install] section.q

Lennart

--
Lennart Poettering, Berlin