[systemd-devel] Is unmounting of filesystem synchronized with stopping services using these filesystems?

[Lennart Poettering]

On Sat, 24.11.12 10:28, Andrey Borzenkov (arvidjaar at gmail.com) wrote:

> According to bootup(7) stopping services and unmounting of filesystems
> happens in parallel. Is there any sort of implicit dependencies between
> running services and filesystems? I do not see anything besides
> dependencies explicitly listed in unit files.
> 
> So am I right to assume that systemd just continues to attempt to
> unmount each filesystem until it succeeds? In this case I'm just
> curious how it happens. As far as I can tell, mount_stop() always
> succeeds, so stop job is always completed. After /bin/umount
> completes, mount_sigchld_event() checks whether filesystem is gone or
> not, and if it is still present it reenters it again in list of active
> units. At which point it immediately conflicts with umount.target and
> it starts all over again.
> 
> Is the above algorithm correct?

Note that normal services are generally ordered after basic.target
(unless DefaultDependencies=no is set for them) which transitively means
they are also ordered after local-fs.target, which is in turn ordered
after the boot-time mount units. Now, since we have the general rule
"the shutdown order is the reverse of the startup order", this also
means that at shutdown, the services with be stopped before the mount
units will be stopped.

At the very end of shutdown, after the unit state engine already got
terminated we have a "brute-force" loop that will the unmount/read-only
mount all file systems that are left at that time. But this is only
intended to be the safety net if the normal unit-based umount logic
didn't work (which can happen if some service with
DefaultDependencies=no keeps a file system busy).

Hope that makes some sense?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.