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

Michal Kara
2002-10-15T15:38:27Z

> 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.

The fork() manpage says:

EAGAIN fork cannot allocate sufficient memory to copy the
parent's page tables and allocate a task structure
for the child.

No word about limits. But that may classify as a manpage problem.

> 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.

I can think only of some applications retrying when they get EAGAIN...

> Your alternative of a klogging an error is not appropriate
> either. Hitting an rlimit is not a system, but a user
> error.

On workstation or multi-user server yes. But not on, say, web server.
There hitting the limit is a problem and administrator should do something
about it. When your nightly processing job hits limit (and when you run it
by hand, it doesn't) , "Something wrong" is not to much helpful to solve the
problem.

> Optimally whatever hit the rlimit should have reported a
> more useful message. That many applications don't have
> special processing for EAGAIN isn't surprising as it doesn't
> occur that often. I suppose a change to the error message
> to read "Resource temporarily unavailable or user limits
> exceeded" might help newer users but that is a property of
> libc.

But WHICH limit. This is what this is all about. If there was only one,
then it is OK. And you cannot even display the limit/usage for running
process to give you a hint.

Michal Kara

--
PING 111.111.111.111 (111.111.111.111): 56 data bytes
...
---- Waiting for outstanding packets ----
No outstanding packets received, just two ordinary.