Re: Better fork() (and possbly others) failure diagnostics

[Pavel Machek <pavel@ucw.cz>]

Hi!

> >   Several times I had real problems with batch jobs failing with EAGAIN,
> > printed as "Resource temporarily unavailable". Not with the failure, but to
> > determine the real cause is really a pain. Usually, the problem is in
> > resource limits (rlimit, set by ulimit), but the returned error code is
> > misleading.
> > 
> >   There are two ways. One is to print something to syslog, when some rlimit
> > is reached. This is already done when limit of open files in system is
> > reached.
> > 
> >   The second is more subtle - define error code for reaching the rlimit
> > (possibly one errorcode for each rlimit) and slightly change the code to
> > return correct error code.
> > 
> >   What do you think about this subject?
> 
> Bad idea at this time.  In 1980 it might have been ok.

I believe it is still good idea.

> Take a look at the manpages.  It is very clear there that
> EAGAIN has two meanings: try again because what you request
> isn't available yet, and request exceeds resource limits (at
> the moment).  Basically POSIX and SUS direct that EAGAIN is
> the correct error code for resource limit exceedance.
> 
> I agree it would be nice if rlimit caused its own error code
> but such a change at this time would break far to many things.

What would break?

> Your alternative of a klogging an error is not appropriate
> either.  Hitting an rlimit is not a system, but a user
> error.  There is nothing for the admin to do, the message

If it is user error, than it is okay if system returns something else
than EAGAIN. We could for example return EUSERERROR_LIMITREACHED. But
I do not really think it is user error.
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org