Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 10797 - "-sh: ulimit: cannot modify limit: Operation not permitted"
"-sh: ulimit: cannot modify limit: Operation not permitted"
Product: Red Hat Raw Hide
Classification: Retired
Component: setup (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
Depends On:
  Show dependency treegraph
Reported: 2000-04-13 13:28 EDT by Jonathan Kamens
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-05-29 09:10:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jonathan Kamens 2000-04-13 13:28:01 EDT
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 13:48:59 EDT
Fixed in setup-2.2.2-1 - ulimit was using the old syntax.
Comment 2 Jonathan Kamens 2000-05-22 00:19:59 EDT
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 08:57:59 EDT
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 09:10:59 EDT
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 19:07:07 EDT
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.