[systemd-devel] proper way for shutdown script

Lennart Poettering lennart at poettering.net
Thu Oct 6 17:12:47 UTC 2016


On Wed, 05.10.16 18:01, Xen (list at xenhideout.nl) wrote:

> Lennart Poettering schreef op 05-10-2016 14:52:
> 
> >>nss_initgroups_ignoreusers
> >>_apt,avahi,avahi-autoipd,backup,bin,colord,daemon,dnsmasq,games,gnats,hplip,irc,kernoops,list,lp,mail,man,messagebus,news,proxy,pulse,root,rtkit,saned,sddm,sshd,sync,sys,syslog,systemd-bus-proxy,systemd-network,systemd-resolve,systemd-timesync,unscd,usbmux,uucp,uuidd,whoopsie,www-data
> >
> >Urgs, what an ugly approach...
> 
> :).
> 
> Still better than a non-booting system :p. So apparently this situation has
> already existed for quite some time.
> 
> Even worse is that by default the ldap configuration is set to bind-policy =
> hard, which can also create this issue (a failing LDAP query will then never
> return, or only return after a long timeout).
> 
> >It's the way to go on systemd. With current systemd you should be able
> >to leave out the ExecStart=/bin/true bit, if you only care about
> >shutdown?
> >
> >But as I understood you actually wanted to run something both at boot
> >and at shutdown, hence why would you not make use of ExecStart= as
> >well here?
> 
> No that's not true.
> 
> I only wanted shutdown.
> 
> If the service never gets started how can it shut down?
> 
> ExecStop does weird things on services that are oneshot but not
> RemainAfterStart, at least.

The way to have a process executed at shutdown is by using ExecStop=
and making sure the unit is started at start-up time.

Current systemd versions permit unit files without any ExecStart= to
cover for this case, really old systemd versions didn't like that, in
which case you need to specify ExecStart=/bin/true for them.

> >Note that the above unit file you posted is a bit contradictory: if
> >you plug something into sysinit.target then your service should be an
> >early-boot service, and those have to have the DefaultDependencies=no
> >setting, as they need to configure their preicse ordering manually,
> >instead of relying on the generic dependencies.
> 
> I realized that, but it works :p. The reason I picked it like this is
> because it *seems* that you might have rescue mode situations in which
> basic.target is never reached, neither is multi-user.target ever reached,
> but sysinit.target will be reached?

Well, but that in case your service won't be reached either, as your
service implicitly depends on basic.target unless you set
DefaultDependencies=no.

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list