1 |
On 02/17/2016 02:01 PM, Andrew Savchenko wrote: |
2 |
> On Tue, 16 Feb 2016 15:18:46 -0500 Rich Freeman wrote: |
3 |
>> On Tue, Feb 16, 2016 at 2:31 PM, Patrick Lauer <patrick@g.o> wrote: |
4 |
>>> |
5 |
>>> The failure message comes from rc-mount.sh when the list of PIDs using a |
6 |
>>> mountpoint includes "$$" which is shell shorthand for self. How can the |
7 |
>>> current shell claim to be using /usr when it is a shell that only has |
8 |
>>> dependencies in $LIBDIR ? |
9 |
>>> As far as I can tell the code at this point calls fuser -k ${list of |
10 |
>>> pids}, and fuser outputs all PIDs that still use it. I don't see how $$ |
11 |
>>> can end up in there ... |
12 |
>> |
13 |
>> What does openrc do when the script fails? Just shut down the system anyway? |
14 |
>> |
15 |
>> If you're going to shut down the system anyway then I'd just force the |
16 |
>> read-only mount even if it is in use. That will cause less risk of |
17 |
>> data loss than leaving it read-write. |
18 |
>> |
19 |
>> Of course, it would be better still to kill anything that could |
20 |
>> potentially be writing to it. |
21 |
> |
22 |
> This is not always possible. Two practical cases from my experience: |
23 |
> |
24 |
> 1) NFS v4 shares can't be unmounted if server is unreachable (even |
25 |
> with -f). If filesystem (e.g. /home or /) contains such unmounted |
26 |
> mount points, it can't be unmounted as well, because it is still in |
27 |
> use. This happens quite often if both NFS server and client are |
28 |
> running from UPS on low power event (when AC power failed and |
29 |
> battery is almost empty). |
30 |
|
31 |
Does `umount -l /path/to/mnt` work on those? |
32 |
|
33 |
> 2) LUKS device is in frozen state. I use this as a security |
34 |
> precaution if LUKS fails to unmount (or it takes too long), e.g. |
35 |
> due to dead mount point. |
36 |
|
37 |
This gives me another reason to justify being a fan of integrating |
38 |
encryption directly into a filesystem or using ecryptfs on top of the |
39 |
VFS. The others were possible integrity concerns (which definitely |
40 |
happen with a frozen state, although mine were about excessive layering |
41 |
adding opportunities for bugs) and performance concerns from doing |
42 |
unnecessary calculations on filesystems that span multiple disks (e.g. |
43 |
each mirror member gets encrypted independently). |
44 |
|
45 |
> As far as I understand, mount-ro may be useful only if unmount |
46 |
> failed, but from my practical experience, openrc just hangs forever |
47 |
> in such case until UPS is shut down by battery drain. |
48 |
|
49 |
It is useful even if mounting everything succeeds because of /. That |
50 |
said, I do not think we can sanely handle every possible configuration |
51 |
because someone will always come up with something new. |
52 |
|
53 |
> Best regards, |
54 |
> Andrew Savchenko |
55 |
> |