On Sat, 24.11.12 10:28, Andrey Borzenkov (arvidj...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
