On Tue, Nov 18, 2008 at 3:52 PM, Peter Miller <[EMAIL PROTECTED]> wrote: > On Tue, 2008-11-18 at 14:15 +1100, Matthew Hannigan wrote: >> On Tue, Nov 18, 2008 at 08:54:47AM +1100, Peter Miller wrote: >> > Ho Folks, >> > >> > yet another puzzle for you. >> > >> > fork(2) can fail and report EAGAIN if >> > a. run out of a resource other than memory >> > b. too many processes on the system >> > c. too many processes per uid >> > d. too many child processes per process >> > >> > for each of the above, on linux, how the heck do you >> > 1. obtain current usage >> > 2. obtain limit >> > >> > afaics getrusage(2) is no help >> > >> > (d)(2) can be done by getrlimit(RLIMIT_NPROC) or sysconf(_SC_CHILD_MAX) >> > except that both man pages are pretty vague as to whether they are (c) >> > or (d). >> > >> > It would be great if libexplain could distinguish between the 4 cases. >> > >> > suggestions? > >> Linus was adamant that he was not going to have such fixed numbers in the >> kernel; that these in principal could certainly change dynamically. >> Per process, per hour, per user or whatever. > > I can see why he doesn't want fixed numbers in the kernel, but that's > not what I'm after. > > <tangent> Posix doesn't insist of fixed numbers, tho (I've been reading > it way too much, lately) so I can't quite see why he would object to the > sysconf() system call supplying at-this-moment numbers. </tangent> > > > Essentially I want to be able to say > > fork() failed, Resource temporarily unavailable (EAGAIN) because the > process has reached its limit of child processes (42) > > ...because the system limit of process for this user (42, "pmiller") has > been reached (666). > > ...because there are too many processes running in the system (42987) > > > I'm happy for the numbers to go up and down, I'm happy to access the > limits via a system call or some /proc groping (throwing another process > is probably impossible in this case, but opening a new file descriptor > may not be), I just want to be able to distinguish the cases, because > the correct action to fix each of them differs. > > > Trying to explain the causes of obscure <errno.h> values is like a > riddle-based mystery tour of Asymmetric Api Land. "Yes, that error > happened; yes, the system knows why; no, the system will not tell you > your crime. Guilty! Ten years imprisonment. Next!"
Oh yeah, it would be really nice if each place that can throw an error returned a unique code. Have fun with mmap. There appears to be about 50 different cases where mmap can fail and most of them appear to simply return EINVAL. I'm not sure how libexplain will tell me mmap failed because the underlying filesystem doesn't support mmap! Cheers, Benno _______________________________________________ coders mailing list coders@slug.org.au http://lists.slug.org.au/listinfo/coders
