Messages in this thread | | | From | "Miquel van Smoorenburg" <> | Subject | Re: How to replace an executing file on an embedded system? | Date | Thu, 2 Jun 2005 00:11:00 +0000 (UTC) |
| |
In article <Pine.LNX.4.61.0506011828300.5925@chaos.analogic.com>, Richard B. Johnson <linux-os@analogic.com> wrote: >The newer linux kernels have this problem: > >Suppose I do this: > >cp /sbin/init foo # Make a copy of 'init' >mv foo /sbin/init # Rename it back (emulate install) >chmod +x /sbin/init # Make sure we can boot. > >When I try to umount() the file-system, it now fails with >EBUSY (16). > >I have tried fsync(), sync(), fsync() on /sbin, etc. I can't >get rid of the busy inodes. > >This reared its ugly head with field software upgrades. We >used to be able to upload new software for every executable >on an embedded system using the network or a serial link. > >This would replace every file. We would then kill all the >tasks except 'init', unmount the file-system and then reboot. >The upgrade was finished. Every lived happily ever after. >But, with newer kernels, we can't.
AFAIK, this has been the cases for basically ever. The inode has been unlinked (st_nlink == 0) but the data blocks are still there on disk, so the file will be deleted once you close it, not earlier - things like that are not remembered over an unmount/mount so the kernel doesn't let you unmount the filesystem, it's really "busy" at that time.
If earlier kernels did let you do that, you basically ended up with a slightly corrupted filesystems (a file present on the fs without a directory entry) and a fsck would probably let it show up again in /lost+found
>What am I missing? How am I supposed to replace files that >are being executed? Do I have to `mv` them to /tmp and >delete them on the next boot? (not easy, we don't have >a shell, I would have to write code to search /tmp). Also >'init' isn't SYS-V 'init'. It's just the startup program >for a system that keeps growing so I need to be able to >upgrade it.
Change init so that if you send it a signal (SIGHUP, whatever) it re-executes itself. That's what /sbin/init in sysvinit does to make it upgradable in-place without reboot, and in fact to make it possible to actually reboot cleanly. Sysvinit goes through great pains to send its internal state from the old to the new init, your init is probably way way simpler and you can manage with command line switches ( execl("/sbin/init", "init", "--restart", NULL) or something )
Mike.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |