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: #!/bin/sh /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 100000. 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 0 $ _ 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... Comments?
Oh, I found this. It is in initscripts (5.1x at least): /etc/rc.d/init.d/functions: # 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 bug reports!