After upgrading to bash-2.04-2, I get "-sh: ulimit: cannot modify limit:
Operation not permitted" every hour from "run-parts /etc/cron.hourly". In
particular, /etc/cron.hourly/inn-cron-nntpsend is the culprit:
/sbin/chkconfig innd && su - news -c /usr/bin/nntpsend
If "su - news" is changed to "su news" the problem goes away, but that's
treating the symptoms, not the sickness :-).
Fixed in setup-2.2.2-1 - ulimit was using the old syntax.
This isn't fixed. The line in /etc/profile setup-2.2.4-1 which reads "ulimit -S
-c 1000000 > /dev/null" needs to have "2>&1" added to the end of it. Otherwise,
I still get these errors from run-parts /etc/cron.hourly, because cron is
apparently setting the hard-limit on core-dump sizes to 0 before calling
run-parts, which means that the shell script is not allowed to increase it to
In short, ">/dev/null" isn't sufficient to suppress errors being sent to stderr.
Just to be curious. My bash (2.04.1(1)-release, bash-2.04-1), prints this
message each time on login. I'm aware of bug
<a href="http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1312">id 1312</a>,
and tried with/without -S and -H. On command prompt, I see:
$ ulimit -c
So, somewhere before login, there is a `ulimit -c 0' call (or equivalent).
This does not show trouth when logging onto console, or when logging as
root (the last one is expectable). Using telnet, xdm, etc all gives me
the same result: core size limit = 0. I can comment out that line in
/etc/profile, and can redirect message to /dev/null, but I _want_ core files,
as I'm developer...
Oh, I found this. It is in initscripts (5.1x at least):
# make sure it doesn't core dump anywhere; while this could mask
# problems with the daemon, it also closes some security problems
ulimit -c 0
So the question is -- where to set ulimit back to reasonable
value for user-level sessions? Pam?
message will be fixed in setup-2.2.6; the initscripts
one in the next initscripts release - thanks for the