4

I have a simple updater bash script, which replaces files by removing the incident old files and copying new files from an archive to the running embedded target root file system. This way, the script may update system files as well as the updater script itself.

Recently I extended the script to handle a read-only file system by remounting with R/W access (mount -o remount,rw /dev/rootfs /), doing its update business and remounting back with R/O access (mount -o remount,ro /dev/rootfs /).

This approach fails, though. Typically, the script fails either at its first run at the point of remounting back with R/O access, or at its second run at the point of remounting with R/W access. Here is a representative error message:

root@device:~# mount -o remount,rw /dev/rootfs /
EXT3-fs (mmcblk0p2): warning: couldn't remount RDWR because of unprocessed orphan inode list.  Please umount/remount instead.
mount: mounting /dev/rootfs on / failed: Invalid argument

After some research (e.g. https://stackoverflow.com/questions/7834667/self-deleting-bash-script), I realized the problem is in the mechanism how opened files are deleted from the file system. I.e., just a link to the file inode is unlinked at the moment of the call, while the file represented by the inode is actually deleted when the file is closed by all programs which use it. So when I remount back to the R/O mode, the links to the inode are gonne while the inode itself is not, causing file system corruption resulting in the listed error. Is this conclusion correct?

Now, I'm interested in how to properly solve the problem. I suppose that avoiding remounting back to R/O mode and rebooting the system is ok, right? But is there a better solution, allowing to remount back to R/O mode and avoiding system reboot?

Please note the solution should be file system type independent. Specifically, I run on ext3/ext4 and ubifs.

Edit: I'm looking for a general solution, which would not require restarting individual services (i.e. understand the system). It is not actually a problem to reboot the system, it just sounds right to return the system to the same state as it was before running the update script, i.e. if the file system was R/O before its execution, it should perhaps be R/O after it as well. But maybe such premise is invalid.

Improve this question
3
  • 3
    The problem seams to be one of logical workflow. Obviously something is still accessing these files, you might want to check those files to see if they have applications accessing them before you try to modify them. And then not modify them if they are being accessed. Until programs with open handles close that handle memory cannot be de-allocated. This is expected and somewhat necessary behavior. You could flag target files with inotify to wait until the file is available for de-allocation and then act. Commented Dec 14, 2015 at 18:05
  • 1
    Maybe you can use something like lsof to find, what is using such script, then kill the script, maybe even the user of it an restart it again (so it would use the new version) - it could be nicer then reboot, but you have to know, what you are doing (what to restart) Commented Dec 14, 2015 at 18:38
  • Thanks @MattJoyce and gilhad for your comments. My question is more general - I've edited the question to stress it. Also thanks shellter for the categorization note, I was not aware of it. I'll ask the moderator for moving the question. Commented Dec 14, 2015 at 19:57

0

Reset to default

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.