[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-man
Subject:    Re: [PATCH] clone.2: Document ENOSPC due to exhaused PIDs
From:       Walter Harms <wharms () bfs ! de>
Date:       2018-08-19 14:07:02
Message-ID: 1064644176.176500.1534687623632 () ox-groupware ! bfs ! de
[Download RAW message or body]



> KJ Tsanaktsidis <ktsanaktsidis@zendesk.com> hat am 19. August 2018 um 02:41
> geschrieben:
> 
> 
> On Sat, Aug 18, 2018 at 1:17 AM Jakub Wilk <jwilk@jwilk.net> wrote:
> >
> > I reproduced this on Linux 4.17. As one would expect, this happens also
> > with fork(2).
> >
> > This seems to contradict the fork(2) man page, which says that EAGAIN is
> > returned when "the maximum number of PIDs, /proc/sys/kernel/pid_max, was
> > reached".
> 
> I took a look at the fork manpage, which says that EAGAIN can be returned for
> four reasons - because of pid_max (which seems to be wrong), because of
> thread-max, because of RLIMIT_NPROC, and because of cgroup pids.max. I
> checked all of these cases on my clone test program and they all return EAGAIN
> except for the pid_max case, which returns ENOSPC.
> 
> The clone(2) docs say that EAGAIN is returned if "Too many process are already
> running; see fork(2)", which seems adequate to cover this off.
> 
> I guess I should submit a second patch to remove pid_max from the list of
> EAGAIN cases in fork(2) and mention it returns ENOSPC instead?
> 

I would suggest sending this to the Linux Test Project and the kernel ML.
I do not think this is intentional.

re,
 wh
[prev in list] [next in list] [prev in thread] [next in thread]