Ok, this is a silly thing, but I've hit it a few times now until I accidentally figured out what happens ... Mount lots of things, now consider unmounting them, "umount -a" looks like the obvious choice. No warnings or errors, but ... trying to start or stop any init script totally trashes your machinen now as it starts and stops a bit of everything. The cause is of course this: rc-svcdir on /lib64/rc/init.d type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1024k,mode=755) which gets unmounted. And then we've lost all system state, so OpenRC will try to start and stop things to get back to the expected state. I'm not sure what's the best way to improve the situation, but it'd be nice if umount -a was a harmless operation that didn't hurt :)
sorry, but `umount -a` is stupid. it will nuke many tmpfs points. this will probably be fixed once openrc starts using /run/, but until then, i see no point in trying to "fix" this.
I agree that umount -a shouldn't hose the system. You would probably need to patch it to explicitly ignore /lib(64)/rc/init.d on Linux systems. Probably a 3-liner.
Also, this *is* a bug. It's not invalid. Moving to WONTFIX (if it lets me).
Also, based on the man page description of umount -a, it may be fixable by removing the /etc/mtab entry for /lib*/rc/init.d. Try it and see. If so, this is a workaround that can be implemented by openr by using the -n option to mount its tmpfs.
The plan for openrc is to move to /run/init.d on linux systems; this will probably happen after 0.10 is released.
I am willing to look into using mount -n for this as suggested in comment #4, but I don't agree with a custom patch for umount to make it ignore this directory.
Reopening.
Note that I bet that OpenRC takes special steps to manually write that entry to /etc/mtab after / is RW. Those steps for OpenRC's tmpfs would just need to be skipped. We also need to test to see whether removing stuff from /etc/mtab REALLY fixes this. Also, Patrick let me know that /etc/mtab is now a symlink to /proc/mounts? We now have a situation where we *don't* want that to be the case (so we can control umount behavior.) So we may want to revert that.
(In reply to comment #8) > Note that I bet that OpenRC takes special steps to manually write that entry > to /etc/mtab after / is RW. Those steps for OpenRC's tmpfs would just need > to be skipped. Actually, I just found that we already use mount -n to mount this directory (see /lib/rc/sh/init.sh). > We also need to test to see whether removing stuff from /etc/mtab REALLY > fixes this. Also, Patrick let me know that /etc/mtab is now a symlink to > /proc/mounts? We now have a situation where we *don't* want that to be the > case (so we can control umount behavior.) So we may want to revert that. That is not actually quite correct. We do not force /etc/mtab to be a link to /proc/mounts, but we don't try to update it if it is (see /etc/init.d/mtab). My understanding of the reason for this is that /etc/mtab has to be a link to /proc/mounts in some environments. Thinking more about this, I don't know of a way for umount -a to not hose a system; there are too many directories you might have to skip... /lib/rc/init.d, /dev, /tmp, /dev/shm, /usr, /run, maybe even /.... The list goes on.... I don't think this is an openrc issue, and I question whether umount -a can be made smart enough to know what to skip.
Yes, you are probably already using -n before / is read-write, but then you are probably doing mount -f to update mtab afterwards. So just eliminate the -f call. To test, do this on a test system: 1) edit /etc/mtab, remove OpenRC tmpfs mountpoint 2) type umount -a 3) See if OpenRC tmpfs mountpoint is still there or not. If it is still there, then finding and eliminating the second mount -f call will fix it.
`umount -a` is already smart enough in that you tell it to ignore tmpfs with the -t flag. the fact that /run and friends don't get unmounted is purely incidental in that some running daemons might have open handles to files in there. so if you boot up a system, shut down a few daemons, and then `umount -a` also takes down /run, people want it to skip that too ? i don't think so. hiding things from /etc/mtab is not a scaleable solution either. we want to move to /proc/self/mounts asap, and it doesn't handle the cases where people have already migrated, or have no interest in moving back. there are plenty of tools in the tree that you can use to shoot yourself in the foot. that doesn't mean we should idiot proof them.
doesn't seem like we have any competing ideas here. the only way to make it truly "work" is if we had a long running daemon that existed merely to hold an open fd to a file inside the dir we didn't want to unmount. but whether that's even a good idea is questionable. invalid because `umount -a` is doing exactly what it's supposed to.
Reopening. OK, let's not leave stuff out of /etc/mtab. Instead, add a new mount option that gets recorded in /etc/mtab, which tells "umount" to skip the filesystem on "umount -a". /run and OpenRC tmpfs mounts would be mounted with this option. This would allow sysadmins to use umount -a to umount all stuff they care about. If you need to umount one of these specially-mounted filesystems, you would need to explicitly call umount on it, in which case umount would try to umount it like normal. umount -a wouldn't touch it. Mount has already has been patched to not umount "/proc" so clearly there has already been some effort in regards to making "umount -a" a command that a super-user can actually find useful. However, the problem with hard-coding umount for each filesystem like /proc is that it is a maintainability nightmare for new things like /run or OpenRC. We can keep hacking "mount" or come up with a better option. I think the option described above is a better option and strikes the right balance. It would be an improvement over the current "hard code umount to skip /proc" junk that currently exists. I don't want to accept current behavior as "correct" because it's clearly not optimal. We don't want to "newbify" commands like umount but we do want them to be useful for sysadmins and I think the approach described above strikes the right balance and is better from a design perspective.
I am re-assigning this since it no longer is an openrc issue, but an issue with util-linux.
as already noted, there's already an option: -t notmpfs if you want something more specific, bug upstream
Spanky, read what I wrote instead of repeating yourself. I know there is a -t notmpfs option. It's not the same thing as what I am proposing. William, this is still an issue related to OpenRC and will require a patch to util-linux and OpenRC. The idea of sending it upstream at this point is not going to work.
there's nothing to patch in openrc. and i'm not accepting a patch to util-linux for an issue that's not a bug. if you want anything to change, then convince upstream util-linux.
The patch to umount would be adding notmpfs directly, and I'm not certain that is safe. We would need changes elsewhere to make sure tmpfs gets unmounted during shutdown after that. Other than systemd/udev running on /run in new systems, is there anything else keeping that, /dev/ and /dev/shm mounted? devtmpfs is NOT in the exclude list either.
(In reply to comment #18) patching `umount -a` to actually mean `umount -a -t notmpfs` is wrong imo. if you don't want to unmount tmpfs partitions, then use the -t flag yourself. /dev generally doesn't get removed because so many things keep open handles to files in there (like /dev/null). `lsof -n` shows many consumers of /dev, including the init process which has /dev/initctl.
(In reply to comment #16) > Spanky, read what I wrote instead of repeating yourself. I know there is a > -t notmpfs option. It's not the same thing as what I am proposing. I think I understand what you are proposing, something like a 'skipumount' mount option, so someone could do: mount -o skipumount /foo/bar Then the filesystem at /foo/bar wouldn't be unmounted on a umount -a call. I would vote against this, because it changes the meaning of umount -a. Now we would need some kind of option to umount to tell it not to skip any file systems marked with this option and all init systems out there would have to be updated to use the new option.
I have opened a Funtoo bug on this issue: http://bugs.funtoo.org/issues/27#change-66 We can explore options on the Funtoo side.
