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