From: Herbert Pötzl (herbert_at_13thfloor.at)
Date: Sat 02 Aug 2003 - 04:32:18 BST
did some investigations regarding the 'strage'
ulimit behaviour in newer 2.4.22-preX kernels ...
first, the 'new' behaviour was 'introduced' in
2.4.22-pre4 (which was the historical reversed
patch from Marcelo =), and it seems, that this
behaviour will stay ...
- what happens?
actually the current limit (in the setrlimit
request to the kernel) is higher than the
maximum allowed limit for this particular
resource ... so the syscall fails with EINVAL
- is it dangerous?
hard to answer, depends on what you expect, or
do with/against it ... ;)
- how can I work around?
simple, just set the 'soft' limit to a lower
or equal value before the hardlimit is reduced.
- why this behaviour?
around Sun Dec 08 2002
Rik van Riel
------------------------------------------------------------------
Wouldn't it be better to simply take the soft limit down to
min(new_rlim.rlim_cur, new_rlim.rlim_max) ?
Peter Chubb
------------------------------------------------------------------
Single unix spec says to return EINVAL in this case.
[EINVAL]
An invalid resource was specified; or in a setrlimit() call,
the new rlim_cur exceeds the new rlim_max.
Rusty Russell
------------------------------------------------------------------
POSIX says -EINVAL, and since it's a programmer fuckup, I'd agree.
so it seems that this 'behaviour' is a coding
error in the ulimit implementation of the shell
and will (hopefully) be fixed in a later release ...
HTH,
Herbert