How to replace an executing file on an embedded system?

How to replace an executing file on an embedded system?

[Richard B. Johnson]

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.

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.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.11.9 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

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

[Bernd Eckenfels]

In article <Pine.LNX.4.61.0506011828300.5925@chaos.analogic.com> you wrote:
> What am I missing?  How am I supposed to replace files that
> are being executed?

The problem is that a unlinked file which is open will be removed from the
filesystem on close. I think this is not new. You can make init reexecute
itself (telinit u)

Gruss
Bernd

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

[Stephen Hemminger]

On Wed, 1 Jun 2005 18:31:07 -0400 (EDT)
"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.
> 
> 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.

The image of the file being executed has to exist because
the text portion could be needed at any time for a page in.

You can move it in the same filesystem (since the open file handle 
stays the same), or even delete it (since it doesn't disappear till
last reference goes away). but you can't unmount the file system because
the inode is still busy.

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

[Al Viro]

On Thu, Jun 02, 2005 at 01:37:17AM +0200, Bernd Eckenfels wrote:
> In article <Pine.LNX.4.61.0506011828300.5925@chaos.analogic.com> you wrote:
> > What am I missing?  How am I supposed to replace files that
> > are being executed?
> 
> The problem is that a unlinked file which is open will be removed from the
> filesystem on close. I think this is not new. You can make init reexecute
> itself (telinit u)

With sysvinit you can, that is.  And no, this behaviour of umount is nothing
new, of course - wrongbot is just being its usual self.

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

[Miquel van Smoorenburg]

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.