Re: How to replace an executing file on an embedded system?

["Miquel van Smoorenburg" <miquels@cistron.nl>]

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/