[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


Lennart Poettering, Red Hat

More information about the systemd-devel mailing list