Ah, right. I had a prod, and I understand what's going on a bit better now--- you're right, upgrading libc (or indeed any libs) will prevent read-only remount of the affected filesystems until the processes using the old libraries die or re-exec.
I couldn't work out why this happened, but is looks like having a _deleted_ file open or mmapped (even if read-only) prevents the filesystem from being remounted readonly. This seems counterintuitive, but I guess the backend reason is to avoid the inode being orphaned in the filesystem. In principle, this could be avoided without keeping the filesystem writable, but it's really a mainline kernel and filesystem issue and not Ubuntu specific. We could work around the issue in the libc upgrade by moving the old libc elsewhere in / instead of deleting it (it must be a real move, not a copy-unlink; I've confirmed that it works). This could possibly be done in the libc6 maintainer scripts. The file can be cleaned up after the next boot. However, it may not be too worthwhile to spend effort on setting this up if there is a longer term plan to make upstart support re-exec'ing itself better anyway... ? -- No further respawns after a "telinit u" https://bugs.launchpad.net/bugs/348346 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
