Bug#453710: [Pbuilder-maint] Bug#453710: [patch] kill the build if the memory/disk is low

[Junichi Uekawa]

Hi,

> > > we need a feature to kill the build if the free disk (or memory) space is running low.
> > > I am attaching a preliminary patch, that implements this feature, it applies cleanly
> > > against the pbuilder in unstable (and also against the git version).
> > >
> > > Documentation needs to be written, but before I do so, I wanted to check if
> > > you'd accept such a patch at all. What do you think about it?
> > >
> > > If you like it, I'll polish it some more, include documentation and send a new patch.
> > > If you don't like it - what is the right way to get this feature in pbuilder?
> >
> >
> > I have a few questions.
> >
> > Does this patch work?  Will it leave some processes around?
> 
> It worked at the time I posted the patch, and it didn't leave some
> processes around. But I agree that
> it's fragile.

If it works fine, that's great. 

I fear it's a bit of a long shell code for the amount of feature it
adds.

> > I am a bit worried that using ulimit and filesystem quota might
> > satisfy the requirements more easily and be much simpler to implement.
> 
> So you propose to leave pbuilder as is, but implement this in the code
> calling pbuilder? I.e.
> to set ulimit and filesystem quota? CCing to Goneri, who uses this in
> svnbuildstat, to
> tell us his opinion on this.

I was worried more about the implementation side, I could add this
feature to pbuilder, because this is generically useful feature (outside
of svnbuildstat).

However, if there is a simpler way to implement this feature using
existing framework, we don't need to let bash do any maths.



RLIMIT_DATA / RLIMIT_RSS etc look like a good candidate for
memory management.

As for disk space, RLIMIT_FSIZE looks useful.  And 'quota' seems more
like a best match.

RLIMIT_NPROC looks like a good idea to avoid DoS, although most
packages would avoid endless forkbombs in their build process.



They are not exact matches to what you do, but I think you want to
catch the obviously wrong behavior, and not when lack of system
resources happens. (well, we do want to catch lack of system
resources, but we want to catch obviously wrong behavior before that).

I'd like to know your ideas.


regards,
	junichi
-- 
dancer@{debian.org,netfort.gr.jp}   Debian Project