update a running busybox

[Laurent Bercot]

> Thanks for your help. I have tried Ralfs approach and it works. Just
> for my understanding (I like to learn more) : can you explain why this
> works? This is not very clear to me. But anyhow, thanks both of you

 It has to do with how the Linux kernel manages deleted files and mounted
filesystems.

 When you unlink a binary that is being executed (for instance:
/bin/busybox), said binary is not deleted at once, because it is still
in use (processes executing it have a fd open on it). The binary is
just marked for deletion; when all processes executing it have exited,
the real deletion occurs.

 To remount / read-only, Linux must be able to guarantee that / will not
change at all after it is remounted, so it makes sure there is no pending
write operation on the root filesystem. That means, no file descriptor
open for writing pointing to a file on the root filesystem, *and* no
pending deletion of a file that is currently in use. (Plus other
esoteric things that are irrelevant here). If one of those conditions
is unmet, "device is busy": / can't be remounted read-only because it
is still being used read-write.
 Processes accessing deleted files must first exit, then the pending
deletion can occur, then the device is not "busy" anymore. Of course,
when the deleted file is the executable for process 1, as is often the
case for /bin/busybox used as a shell, it is not easy to do this cleanly...

 Renaming /bin/busybox to /bin/busybox.old solves the problem because
there is no pending deletion operation: processes that were executing
/bin/busybox are now executing /bin/busybox.old, and nothing prevents /
from being remounted read-only. After you reboot, processes are executing
the new /bin/busybox, nothing is executing /bin/busybox.old, so you can
unlink /bin/busybox.old and have it immediately deleted from the disk,
then remount / read-only without trouble.

-- 
 Laurent