On Tue, 2007-03-27 at 15:14 +0100, Mark McLoughlin wrote:
# TODO: need to handle when unmount fails because of lingering
# processes that has open files
self.bindmounts.reverse()
for b in self.bindmounts:
b.umount()
Is the idea here that an exception is thrown all the way up to the user if unmount fails because some process in the chroot have open files?
I guess that's fine; long term I'm hoping we can slay them somehow.. it does happens from time to time since that packages inevitably do a 'service foo restart' instead of 'service foo condrestart'...
David
On Mon, 2007-04-02 at 00:29 -0400, David Zeuthen wrote:
On Tue, 2007-03-27 at 15:14 +0100, Mark McLoughlin wrote:
# TODO: need to handle when unmount fails because of lingering
# processes that has open files
self.bindmounts.reverse()
for b in self.bindmounts:
b.umount()
Is the idea here that an exception is thrown all the way up to the user if unmount fails because some process in the chroot have open files?
In this case, given the choice between returning a nice error to the user and letting an exception propagate back up to the toplevel, I'd go with the latter. This is a programming error in that the tool has sucked and there's nothing the user can do to help. So, returning a nice error here might make us feel better, but doesn't help the user[1].
umount() doesn't even through an exception right now, though. It probably should.
I guess that's fine; long term I'm hoping we can slay them somehow.. it does happens from time to time since that packages inevitably do a 'service foo restart' instead of 'service foo condrestart'...
Yep, that'd be the best way of handling it ... it's not just unmounting the bind mount that could fail because of this, though. The process could just as easily have files open in /usr.
Cheers, Mark.
[1] - Um, I'm not trying to lecture here btw ... I'm just trying to get my own head around what's a good error handling strategy when coding with exceptions :-)
livecd@lists.fedoraproject.org