On Tue, Sep 11, 2012 at 04:15:27PM +0200, Lennart Poettering wrote: > On Tue, 11.09.12 16:06, Zbigniew Jędrzejewski-Szmek ([email protected]) wrote: > > > > Yes, this seems right. > > > > > > Now, the question is what to do about it... I really have no nice way > > > out here short of biting the bullet and adding the ability of allowing > > > configuration of shutdown ordering that is not just the inverse of the > > > startup ordering. Then we could still allow the mount to be unordered > > > against remote-fs at startup but order it at shutdown. > > > > > > Hmm, Michal, Kay, do you guys have any suggestions what we could do here? > > > > What about retrying the unmounting after a delay if EBUSY is encountered? > > sysvinit scripts seem to do that usually. > > I think we really should try hard to avoid things like that for the > "clean" code paths. > > But dunno, maybe relying on MNT_DETACH might be a good idea here? Mounts are special in this regard, and might require special treatment.
Using MNT_DETACH would sometimes only hide the problem: let's say that we have a fuse filesystem (e.g. ecryptfs). There's no simple order for unmounting which would work, because it is necessary to first 1. kill or terminate all process accessing the mountpoint 2. umount and get rid of the fuser helper process 3. umount other filesystems that the fuser helper process was using Zbyszek _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
