On Tue, 16 Feb 2016 15:18:46 -0500 Rich Freeman wrote: > On Tue, Feb 16, 2016 at 2:31 PM, Patrick Lauer wrote: > > > > The failure message comes from rc-mount.sh when the list of PIDs using a > > mountpoint includes "$$" which is shell shorthand for self. How can the > > current shell claim to be using /usr when it is a shell that only has > > dependencies in $LIBDIR ? > > As far as I can tell the code at this point calls fuser -k ${list of > > pids}, and fuser outputs all PIDs that still use it. I don't see how $$ > > can end up in there ... > > What does openrc do when the script fails? Just shut down the system anyway? > > If you're going to shut down the system anyway then I'd just force the > read-only mount even if it is in use. That will cause less risk of > data loss than leaving it read-write. > > Of course, it would be better still to kill anything that could > potentially be writing to it. This is not always possible. Two practical cases from my experience: 1) NFS v4 shares can't be unmounted if server is unreachable (even with -f). If filesystem (e.g. /home or /) contains such unmounted mount points, it can't be unmounted as well, because it is still in use. This happens quite often if both NFS server and client are running from UPS on low power event (when AC power failed and battery is almost empty). 2) LUKS device is in frozen state. I use this as a security precaution if LUKS fails to unmount (or it takes too long), e.g. due to dead mount point. As far as I understand, mount-ro may be useful only if unmount failed, but from my practical experience, openrc just hangs forever in such case until UPS is shut down by battery drain. Best regards, Andrew Savchenko