# Why remount RO before shutdown ?

## javeree

Let me axplain the background of this question. Yesterday I was remotely logged in on a PC with a usb harddisk attached. I saw there was some big problem with that disk (df froze, ls on the mount point froze, ....)

I thought the easiest way to solve this (didn't feel like it was worth my time debugging) was a reboot. So I remotely reboot ... and can't get in anymore.

Back home, I find that the shutdown was hung on the 'trying to remount hardddisk ro'. 

Now this leads me to a general question: why does linux want to remount a disk ro before shutdown. I would guess that a simple sync  and unmount might be sufficient. 

I can imagine some kind of reason for the disk where /sbin is mounted. One might still want to access some command stored there after the disk / is unmounted. However, I wonder what kind of stuff that might be, and if it is not better solved with some reordering of the actions.

So I hope someone can explain the general reason why this remounting is done, and especially if it is also needed for disks like usb disks or in general disks dat carry only data.

Hoping to learn something here.

----------

## MacGyver031

The simplest thing to show that reordering cannot be done is the following: You cannot power off the system and then unmount the disk, can you?

Other things are you will have to send shutdown command to your UPS, here you require commands stored in bin and sbin.

There are many other cases where the unmount of a disk is done prior to executed commands which lay on the disk.

I hope you get the point.

----------

## aCOSwt

 *javeree wrote:*   

> So I hope someone can explain the general reason why this remounting is done

 

1/ The root filesystem needs to be accessible (mounted) until the poweroff triggered by the call to /sbin/poweroff. (Or you will not find the program for powering your system off)

2/ Some variable amount of time will elapse between the last sync (commit of the buffers) to the root filesystem and the poweroff. There must not be any writing done within this time otherwise the filesystem might well be in an inconsistent state when rebooting.

3/ Re-mounting is the only way to change from a RW mount to a RO one.

Remounting root RO is a good way to ensure the availability of /sbin/poweroff while ensuring nothing will be written to the filesystem after last sync.

----------

## BitJam

As the others have said, remount ro is the safest and sanest thing to do.  It seems the problem you had was not caused by remounting.  Perhaps you had a hardware problem.  If the ls command hangs, it is not surprising that remount ro would hang too.  IOW, your system hanging when it was trying to remount the root file system ro was a symptom of the problem, not the cause.

----------

## javeree

I think the points raised by aCOSwt are all valid, and I can understand the need to read the root filesystem in order to read the poweroff command and possibly others.

However, the case I tripped over was the attempt of the system to remount a detachable USB harddrive, that carried only user data, and nothing needed to run the system.

So in that case, (@MacGyver031) I would think that yes, I can unmount the disk and then poweroff

I also agree with BitJam that the hang was a symptom of whatever was wrong with the disk and not the cause, however, my point is that this symptom could have been avoided.

Since only the root disk (or more general, only the disks where /bin /sbin are) needs to be remounted ro, it should be possible to do a umount -f of all disks that don't contain /bin or /sbin, and a remount of only the needed disks). With that setup, the system would have restarted, even with this 'bad disk' present.

----------

## BitJam

 *javeree wrote:*   

> I also agree with BitJam that the hang was a symptom of whatever was wrong with the disk and not the cause, however, my point is that this symptom could have been avoided.
> 
> Since only the root disk (or more general, only the disks where /bin /sbin are) needs to be remounted ro, it should be possible to do a umount -f of all disks that don't contain /bin or /sbin, and a remount of only the needed disks). With that setup, the system would have restarted, even with this 'bad disk' present.

 

I work on LiveUSB and LiveCD systems where there is sometimes a whole lot of wacky mounting going on.  For example, it is common to have the root file system mounted on a file that is mounted on another file system.  In my experience, remounting read-only is almost always easier than unmounting.  By this I mean that in almost every circumstance where I could unmount a file system, I could have first remounted it read-only. 

If you can replicate a situation where it is possible to unmount a file system that is impossible to remount read-only then I would be very interested it knowing about it.   I agree it is a bug if it is impossible to shutdown a computer.  I'm not convinced that umounting instead of remounting read-only is the solution.   In fact, IIRC, shutdown scripts I've written try to first unmount everything they can and only after that fails do they go back and try to remount the remaining file systems read-only.

----------

## javeree

Some wise comments indeed.

You are probably right that in the case that I've experienced an unmount might have failed as well.

It's not a hot topic, I just will put it on my list of thing to do some time in an indetermined future to see if I can tweak which disks need a remount and which dont.

Now assuming that unmount would also have failed, you state 'it is a bug if it is impossible to shutdown a computer'. I am sure this can and will be disputed by many (I am not even sure I agree with it), but I wonder if some workaround is not possible where the shutdown process is guarded by some timer. If shutdown take longer than <configurable> seconds (e.g. 5 minutes, forget about a clean shutdown and just try to poweroff/shutdown without caring about clean unmounts and such. I know this is a horror to many, but it is the same as what I did when I found the system hanging.

----------

## BitJam

 *javeree wrote:*   

> Now assuming that unmount would also have failed, you state 'it is a bug if it is impossible to shutdown a computer'. I am sure this can and will be disputed by many (I am not even sure I agree with it), but I wonder if some workaround is not possible where the shutdown process is guarded by some timer. If shutdown take longer than <configurable> seconds (e.g. 5 minutes, forget about a clean shutdown and just try to poweroff/shutdown without caring about clean unmounts and such. I know this is a horror to many, but it is the same as what I did when I found the system hanging.

 

Yes.  This type of solution has a much better chance at success than replacing remount with umount.

----------

## i92guboj

Moved from Gentoo Chat to Kernel & Hardware.

----------

## radio_flyer

 *javeree wrote:*   

> 
> 
> Now assuming that unmount would also have failed, you state 'it is a bug if it is impossible to shutdown a computer'. I am sure this can and will be disputed by many (I am not even sure I agree with it), but I wonder if some workaround is not possible where the shutdown process is guarded by some timer. If shutdown take longer than <configurable> seconds (e.g. 5 minutes, forget about a clean shutdown and just try to poweroff/shutdown without caring about clean unmounts and such. I know this is a horror to many, but it is the same as what I did when I found the system hanging.

 

That's called a watchdog timer.

If the system is hung at shutdown for 5 minutes, it's probably no longer in a state where any rc-script/software action is possible, period. It's as likely to be a hardware bug as a software one, and the CPU is probably in full stop. You need something that does the same thing you did, namely, push the reset button. That means a hardware watchdog timer of some sort. Very common on embedded Linux systems, but less so on desktops/laptops where finger-on-reset-button has the same effect without the added cost. I've also seen add-in watchdog timer cards for high-availability servers and the like. This isn't something software can fix.

----------

