🚀 go-pugleaf

On Sun, Apr 21, 2013 at 12:14:59AM +0000, Taylor R Campbell wrote:
>    Date: Sun, 21 Apr 2013 00:10:01 +0000
>    From: Taylor R Campbell <campbell+netbsd-tech-kern@mumble.net>
> 
>       Date: Sun, 21 Apr 2013 01:12:06 +0200 (CEST)
>       From: iMil <imil@home.imil.net>
> 
>       I've just witnessed it with a couple of packages:
> 
>       multimedia/vlc:
> 
>          CC       input/libvlccore_la-stream_memory.lo
>       /scratch/multimedia/vlc/work/.wrapper/bin/gcc: Cannot fork
>       /scratch/multimedia/vlc/work/.wrapper/tmp/logic: Cannot fork
>       /usr/pkg/bin/libtool: Cannot fork
> 
>       I guess I'm too short in memory to play that game :)
> 
>    You probably need to bump the maxproc ulimit (ulimit -p).  The default
>    soft limit is ridiculously low for modern machines, and does not scale
>    with the available RAM as it probably ought to.  I set it to 1044, the
>    default hard limit.
> 
> ...that is, assuming you are doing a highly parallel (high MAKE_JOBS
> or many pbulk slaves) build.  If not, it is curious that the failure
> should manifest in fork in particular and not in a variety of ways or
> in a way that is obviously related to memory exhaustion.

I'm fairly sure that fork work fail (cleanly) for 'lack of physical
memory' or 'lack of KVA', at least not without the world exploding
at the same time. So I'd guess you are just hitting the 'ulimit -p'
soft limit on the number of processes.

The default soft and hard limits for all the 'ulimit' values are 'wrong'
in just so many ways! Mostly because the 'hard' limits for each user
match the kernel hard limits - which are based on MAXUSERS (16).

I suspect some of the hard limits pre-date dynamic allocation of the
relevant structures, these days limiting on the dyanmic availability
of memory/swap and KVA would be more appropriate.

	David

-- 
David Laight: david@l8s.co.uk