On Sat, Jul 17, 2004 at 06:51:19PM +0200, Thiemo Seufer wrote:
> Wouter Verhelst wrote:
> > On Sat, Jul 17, 2004 at 10:58:57AM +0200, Goswin von Brederlow wrote:
> > > Wouter Verhelst <wouter@grep.be> writes:
> > > > In any case, buildd doesn't write to disk what it's doing (the
> > > > build-progress file is written by sbuild), so if it's aborted
> > > > incorrectly (i.e., it doesn't have time to write a REDO file), that
> > > > information goes lost.
> > > >
> > > > That's probably a bug, but once you know about it, it's easy to work
> > > > around (it just means you have to clean up after a crash, but you have
> > > > to do that anyway, so...)
> > >
> > > Which is one of the things realy screwed up on the buildd/sbuild
> > > combination.
> >
> > What's your alternative?
>
> Obviously to clean the chroot automatically unless a clean-buildd-shutdown
> flag was written. Shouldn't be hard to implement.
I'd like to see that implemented properly. There are a number of issues
I can think of offhand that would make it hard:
* the system crash might the result of the build itself. Runaway
memory-eating loop, causing the swapper to trash so horribly that a
power cycle is the fastest way to get it up and running again, for
example. Yes, those happen. In such a case, you don't want to wipe out
the chroot; you want to check out what went wrong, and you might need
whatever's in the chroot to find out.
* unstable is a moving (and breaking) target. Doing a debootstrap --
especially when tried noninteractively -- doesn't always work. And
yes, we need the chroot to be unstable. Think about it.
There are probably more things I could come up with, but I didn't try
hard. Wiping out and recreating the buildd chroot isn't an option.
Neither is creating a new one alongside the original, unless the disk
space requirements are a non-issue (which isn't true for some of our
archs).
The only other option I could think of is to implement an AI that would
investigate the chroot and remove any anomalies before restarting the
next build, obviously all the while creating a perfectly detailed log
(as in, exactly the amount of details you'll need to learn about what
went wrong; nothing more and nothing less). That'd be nice to have, I'd
say... ;-)
Really, such cleanups can't be properly automated IMO. I agree that
there are cases where buildd could be improved, but that doesn't mean
manual cleanups can be avoided; and after a system crash, if a cleanup
is required, it must be done manually.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
Attachment:
signature.asc
Description: Digital signature