Re: [Fedora-livecd-list] [patch 06/20] Cleanup unmount() and teardown()

[David Zeuthen]

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

[patch 06/20] Cleanup unmount() and teardown()

[Mark McLoughlin]

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 :-)