Bug 10797 - "-sh: ulimit: cannot modify limit: Operation not permitted"
Summary: "-sh: ulimit: cannot modify limit: Operation not permitted"
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: setup
Version: 1.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-04-13 17:28 UTC by Jonathan Kamens
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2000-05-29 13:10:31 UTC

Attachments (Terms of Use)

Description Jonathan Kamens 2000-04-13 17:28:01 UTC
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 :-).

Comment 1 Bernhard Rosenkraenzer 2000-04-13 17:48:59 UTC
Fixed in setup-2.2.2-1 - ulimit was using the old syntax.

Comment 2 Jonathan Kamens 2000-05-22 04:19:59 UTC
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.

Comment 3 Michael Tokarev 2000-05-29 12:57:59 UTC
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...


Comment 4 Michael Tokarev 2000-05-29 13:10:59 UTC
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?

Comment 5 Bill Nottingham 2000-06-10 23:07:07 UTC
message will be fixed in setup-2.2.6; the initscripts
one in the next initscripts release - thanks for the
bug reports!

Note You need to log in before you can comment on or make changes to this bug.