uOn Sun, Apr 24, 2011 at 9:42 PM, Seblu wrote:

On Sat, Apr 23, 2011 at 4:32 PM, Tom Gundersen wrote:

...

If someone knows of any reason not to unmount tmpfs or ramfs on shutdown, please speak up.

So the question, was, is there a reason to unmount ramfs at shutdown? I understand the unmount chaining issue, but i don't see which case is problematic, do you have a ticket # ?

I assume you already saw FS#19783? If we agree that tmpfs should be unmounted (due to the chaining), then ramfs should be too (as anyone might use ramfs in place of tmpfs). We do not unmount tmpfs if /dev is mounted on tmpfs, but this can (no longer) happen on ramfs, so we always unmount it. As Thomas points out in the bug report, it might be that we don't actually need to unmount the file systems at all (only remount them ro). However, this would need to be analyzed a bit more closely. Consider this hypothetical case: a process X (some userspace filesystem daemon) cannot be killed as long as a mount Y is mounted process X has a file opened rw on mount Z (maybe a logfile on /var) a tmpfs/ramfs is a submount of Y Remounting everything ro will not work in such a scenario, so we would need to unmount Y and the tmpfs/ramfs. I don't know if this is actually happening with any setups we support, it might be worth looking into what others are doing. I have been looking at what systemd is doing and it seems quite robust. Their shutdown binary doesn't seem to work for us though.

2 small points about your patch: - You should use /bin/grep and not grep, like everywhere else. - A comment before the if then else to explain why we do this will be cool.

Good points, I'll fix this up once we have agreed on the final solution. -t

On Mon, Apr 25, 2011 at 2:42 AM, Seblu wrote:

On Sun, Apr 24, 2011 at 11:55 PM, Tom Gundersen wrote:

...

a process X (some userspace filesystem daemon) cannot be killed as long as a mount Y is mounted process X has a file opened rw on mount Z (maybe a logfile on /var) a tmpfs/ramfs is a submount of Y

Tricky case. Unmouting tmpfs will not solve the case. Mount Z cannot be unmounted until X process stop and process cannot unmount until it stop to write his log. It's a bad designed mounting.

Solutions would be: unmount -a (this unmounts Y and its submounts) killall (this kills X) unmount -a (this unmounts Z)

...

I have been looking at what systemd is doing and it seems quite robust. Their shutdown binary doesn't seem to work for us though. And what's your conclusion?

That we should look to it for inspiration (and that we sadly cannot use it...).

Another question why we don't unmount _netdev marked fs? Network fs should not be unmounted?

I don't know why this is not done, I would have thought that a forced unmount of _netdev would be needed just as unmounting tmpfs would. I think a proper solution would be to write a tool that would do something like the following: 1) remount everything ro 2) if it fail kill everything and try again 3) if it still fails unmount everything 4) if it still fails kill everything and try again (with we should loop the retries until they time out where it makes sense) It would probably make sense to do the unmounting/killing manually by parsing /proc/self/mountinfo and /proc, which would allow us to blacklist mounts (/dev, /run, /proc, /sys,...) and processes (as requested on FS). Alternatively, we could look into what it would take to be able to use the systemd shutdown binary which does something like this already (and should in principle work independently of systemd). Until someone writes something like this, I suggest we keep the commit I made (with your fixes added), as the "least wrong" solution for now. -t