[systemd-devel] How to keep certain services or mounts active during shutdown?

[Lennart Poettering]

On Thu, 02.07.15 12:24, Frank Steiner (fsteiner-mail1 at bio.ifi.lmu.de) wrote:

> Hi,
> 
> for our diskless clients I setup the network and the root fs in the 
> kernel/initrd and do two additional mounts in the initrd which are
> specific for every client.
> 
> I understand the boot concept with its dependencies and ordering but I've 
> no idea how to influence the shutdown process in two ways:
> 
> 1. I want to keep the network running. To avoid problems with dependencies
>    I had to keep it enabled although all the stuff is done in the kernel/initrd.
>    Thus, it shuts down during reboot and the diskless client hangs
>    of course.

This really depends on the network management service you are
using. networkd won't shut down any network connections when you
terminate it for example.

Which one are you using?

> 2. The two additional NFS mounts should be kept active, too. There are no
>   *.mount files for them in /run/systemd/generator, because they are
>   mounted in the initrd I guess.
> 
>   Is there a way to exclude certain (NFS) mounts from the umount target
>   (or from sth. else?) during shutting? No matter if they have a *.mount
>   in /run/ or not?

For all mounts created via /etc/fstab, with the exception of mounts
for / and /usr itself, systemd will unmount the file systems after all
units dependning on them have terminated.

Not sure if I grok why you want to do what you want to do (after all:
if every user of your two NFS mounts are gone, why keep them around?),
but you can do what you want by writing native .mount unit files for
the file systems and the set DefaultDependencies=no. This will remove
the implicit Conflicts= dependencies for shutdown.target. With those
removed systemd won't try to unmount the mounts during the normal
shutdown phase (unless there are mounts below them that are unmoutned, of
course...).

Note though that there are actual two shutdown phases: the normal one
that strictly follows unit dependencies, and which you can influence
this way. And a final one, that then tries to clean-up everything that
was left over by that first phase. It's basically a umount loop that
tries to unmount everything until it cannot unmount anything
anymore. You cannot really influence that loop though, but it really
shouldn't matter, since at that point there's nothing running anymore
anyway, except PID 1...

Lennart

-- 
Lennart Poettering, Red Hat