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
