[systemd-devel] Temporarily stopping a service while oneshot is running

[Lennart Poettering]

On Thu, 30.03.17 21:42, Kai Krakow (hurikhan77 at gmail.com) wrote:

> Am Thu, 30 Mar 2017 16:13:25 +0200
> schrieb Lennart Poettering <lennart at poettering.net>:
> 
> > On Tue, 21.03.17 07:47, Ian Pilcher (arequipeno at gmail.com) wrote:
> > 
> > > I have a oneshot service (run from a timer) that updates the TLS
> > > certificates in my mod_nss database.  Because NSS doesn't support
> > > concurrent access to the database, I need to temporarily shut down
> > > Apache while the certificate update service is running.
> > > 
> > > Currently, I'm using the following entries in my .service file to
> > > accomplish this:
> > > 
> > >   [Unit]
> > >   Description=Update TLS certificates in mod_nss database
> > >   # Restart Apache, even if this service fails for some reason
> > >   OnFailure=httpd.service
> > > 
> > >   [Service]
> > >   Type=oneshot
> > >   # Shut down Apache to avoid concurrent access to the mod_nss
> > > database ExecStartPre=/usr/bin/systemctl stop httpd.service
> > >   ExecStart=/usr/local/bin/update-nss-certs
> > >   ExecStartPost=/usr/bin/systemctl start httpd.service
> > > 
> > > Is this the best way to do this?  (I can't escape the feeling that
> > > there ought to be a more idiomatic way of accomplishing this.)  
> > 
> > Yes, this appears to be the best, and simplest way to do this to me.
> 
> Isn't there a chance that this introduces races when triggered while a
> bigger transaction is being executed by systemd? It always feels wrong
> to trigger actions that may affect the transaction that is currently
> being executed...

Races I don't see. systemd will merge multiple ongoing
transactions. As long as you only have "positive" transactions merging
is always predictable. But if you mix "positive" with "negative"
transactions (i.e. start jobs and stop jobs for the same units), then
of course the transaction scheduled last wins. If you have those then
of course it might not always be clear what will be in effect in the
end...

Lennart

-- 
Lennart Poettering, Red Hat