> 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.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:55 EST