On 02/17/2016 02:01 PM, Andrew Savchenko wrote:
> On Tue, 16 Feb 2016 15:18:46 -0500 Rich Freeman wrote:
>> On Tue, Feb 16, 2016 at 2:31 PM, Patrick Lauer <patr...@gentoo.org> 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).

Does `umount -l /path/to/mnt` work on those?

> 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.

This gives me another reason to justify being a fan of integrating
encryption directly into a filesystem or using ecryptfs on top of the
VFS. The others were possible integrity concerns (which definitely
happen with a frozen state, although mine were about excessive layering
adding opportunities for bugs) and performance concerns from doing
unnecessary calculations on filesystems that span multiple disks (e.g.
each mirror member gets encrypted independently).

> 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.

It is useful even if mounting everything succeeds because of /. That
said, I do not think we can sanely handle every possible configuration
because someone will always come up with something new.

> Best regards,
> Andrew Savchenko

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to