Bug 495035 - /etc/profile overrides limits.conf core dump size setting
/etc/profile overrides limits.conf core dump size setting
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: setup (Show other bugs)
10
All Linux
low Severity urgent
: ---
: ---
Assigned To: Ondrej Vasik
Fedora Extras Quality Assurance
:
: 506675 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-09 05:02 EDT by Anthony de Almeida Lopes
Modified: 2009-06-18 08:42 EDT (History)
5 users (show)

See Also:
Fixed In Version: setup-2.8.3-1.fc12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-11 09:46:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Anthony de Almeida Lopes 2009-04-09 05:02:56 EDT
/etc/profile, provided by this setup package imposes ulimits on all shells that use this file. This is incorrect. Policy is dicated,currently, by /etc/security/limits.conf or /etc/security.limits.d, certainly not a bash script.

Please remove the ulimit here. 

Expected resuts:
 Settings in limits.conf affect newly spawned shells

Actual results:
 Settings in limit.conf for core files have no affect on newly spawned shells


Other people have this problem as well:
http://forums.fedoraforum.org/archive/index.php/t-19059.html
http://aplawrence.com/Linux/limit_core_files.html
(older, but still relevant)
http://en.linuxreviews.org/HOWTO_enable_core-dumps
Comment 1 Ondrej Vasik 2009-04-09 07:23:02 EDT
Thanks for suggestion, it is necessary to keep core dumps disabled by default (consider production machines). Additionally - it's not only /etc/profile, but /etc/csh.cshrc as well (setting coredumpsize limit to 0). You could easily override those settings by customized script in /etc/profile.d/ anyway... (as was recommended in one of the discussion threads you provided)

I agree that the current situation should be improved somehow. Nowadays pam (where is default /etc/security/limits.conf) is installed almost everywhere, so in the case of the uncomented default setting core 0 in limits.conf, it should be safe to remove that from setup profile/csh.cshrc scripts. Adding pam maintainer to cc...
Comment 2 Tomas Mraz 2009-04-09 08:08:37 EDT
If I am right (I just tested it on rawhide) the kernel default for the core soft limit already is 0. So it should be safe to drop the setting from the profile/csh.cshrc scripts.
Comment 3 Ondrej Vasik 2009-04-10 04:35:48 EDT
Thanks Tomas, I tried that on rawhide machine as well, it's really set to 0 there.  But on F10 machine it's nonzero, so those ulimit / limit commands should be kept there. Will remove this stuff from Rawhide setup and close that bugzilla RAWHIDE or NEXT_RELEASE, as I guess it's not good idea to change that in F-10.
Comment 4 Ondrej Vasik 2009-05-11 09:46:18 EDT
Closing RAWHIDE, already built there as setup-2.8.3-1.fc12 . I do not plan to update F-10/F-11 setup, unless the kernel default for core soft limits will be changed to 0 there.
Comment 5 Tomas Mraz 2009-06-18 08:42:46 EDT
*** Bug 506675 has been marked as a duplicate of this bug. ***

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