Messages in this thread | | | Date | Tue, 15 Oct 2002 17:46:21 +0200 | From | Michal Kara <> | Subject | Re: Better fork() (and possbly others) failure diagnostics |
| |
> 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/
| |