setting core dump size to above 0 does not work in /etc/security/limits.conf

Bug #314222 reported by LimCore
24
This bug affects 1 person
Affects Status Importance Assigned to Milestone
pam (Ubuntu)
Fix Released
High
Steve Langasek
Jaunty
Fix Released
High
Steve Langasek

Bug Description

Ubuntu 8.04 amd64
ii libpam-modules 0.99.7.1-5ubuntu6.1

Hi, after setting:

$ grep core /etc/security/limits.conf

# - core - limits the core file size (KB)
* hard core 409600
* soft core 102400
#* soft core 0

and rebooting,
I get ulimit -a

core file size (blocks, -c) 0

for both the root ( as written in bug#65244 )
and for the users - this seems like a bug to me.

Related branches

Revision history for this message
Jonathan Marsden (jmarsden) wrote :

These limits work as they should for users in Intrepid 8.10 amd64.
I don't have an 8.04 Hardy server to test with. It would be
good to have someone else independently verify this issue on 8.04 Hardy.

Note that for root limits you need to specify the root username:

root hard core 409600
root soft core 102400

per bug #65244 which I created a path to fix (just
improved documentation) for some months back.

Jonathan

Revision history for this message
Jonathan Marsden (jmarsden) wrote :

One more note: when testing this there is no need for a reboot.
A simple logout and login is quite sufficient.

Jonathan

Revision history for this message
LimCore (limcore) wrote :

Well on mine 8.04 amd64 box it seems, as illustrated, that it does not work at all.

ulimit -a shows 0 core for root as well as user (the later is the bug).

Interestingly, despite the results which I pasted, still a core dump WAS created when my tor server crashed.

Revision history for this message
Steve Langasek (vorlon) wrote :

I'm not sure if the problem in 8.04 has the same cause as what I'm seeing in jaunty, but it appears that setting any system default limits at all is broken in jaunty. (Setting per-user limits works correctly, including for root.) I have a good idea what change is to blame for this, and will have a look at getting this fixed for 9.04.

Changed in pam:
assignee: nobody → vorlon
importance: Undecided → High
status: New → Confirmed
Steve Langasek (vorlon)
Changed in pam:
status: Confirmed → In Progress
Steve Langasek (vorlon)
Changed in pam:
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package pam - 1.0.1-9ubuntu1

---------------
pam (1.0.1-9ubuntu1) jaunty; urgency=low

  * Merge from Debian unstable
  * Remaining changes:
    - debian/libpam-modules.postinst: Add PATH to /etc/environment if it's not
      present there or in /etc/security/pam_env.conf. (should send to Debian).
    - debian/libpam0g.postinst: only ask questions during update-manager when
      there are non-default services running.
    - debian/patches-applied/series: Ubuntu patches are as below ...
    - debian/patches-applied/ubuntu-fix_standard_types: Use standard u_int8_t
      type rather than __u8.
    - debian/patches-applied/ubuntu-no-error-if-missingok: add a new, magic
      module option 'missingok' which will suppress logging of errors by
      libpam if the module is not found.
    - debian/patches-applied/ubuntu-regression_fix_securetty: prompt for
      password on bad username.
    - debian/patches-applied/ubuntu-rlimit_nice_correction: Explicitly
      initialise RLIMIT_NICE rather than relying on the kernel limits.
    - debian/patches-applied/ubuntu-user_defined_environment: Look at
      ~/.pam_environment too, with the same format as
      /etc/security/pam_env.conf. (Originally patch 100; converted to quilt.)
    - Change Vcs-Bzr to point at the Ubuntu branch.
    - debian/local/common-password, debian/pam-configs/unix: switch from
      "md5" to "sha512" as password crypt default.

pam (1.0.1-9) unstable; urgency=low

  * Move the pam module packages to section 'admin'.
  * 027_pam_limits_better_init_allow_explicit_root: defaults need to be
    declared as LIMITS_DEF_DEFAULT instead of LIMITS_DEF_ALL, otherwise
    global limits will fail to be applied. LP: #314222.

pam (1.0.1-8) unstable; urgency=low

  * Updated debconf translations:
    - Bulgarian, thanks to Damyan Ivanov <email address hidden> (closes: #518121)
    - Spanish, thanks to Javier Fernandez-Sanguino Peña <email address hidden>
      (closes: #518214)
    - Swedish, thanks to Martin Bagge <email address hidden> (closes: #518324)
    - Vietnamese, thanks to Clytie Siddall <email address hidden>
      (closes: #518329)
    - Japanese, thanks to Kenshi Muto <email address hidden> (closes: #518335)
    - Slovak, thanks to Ivan Masár <email address hidden> (closes: #518341)
    - Czech, thanks to Miroslav Kure <email address hidden> (closes: #518992)
    - Portuguese, thanks to Américo Monteiro <email address hidden>
      (closes: #519204)
    - Galician, thanks to Marce Villarino <email address hidden>
      (closes: #519447)
    - Romanian, thanks to Eddy Petrișor <email address hidden>
      (closes: #520552)
  * 027_pam_limits_better_init_allow_explicit_root: set the RLIMIT_MEMLOCK
    limit correctly to match the kernel default, which is not RLIM_INFINITY.
    Closes: #472629.

 -- Steve Langasek <email address hidden> Fri, 20 Mar 2009 19:12:10 -0700

Changed in pam:
status: Fix Committed → Fix Released
Revision history for this message
spiceisland (graham-hudspith) wrote :

Yep, can confirm that the fix for this problem also fixes https://bugs.launchpad.net/ubuntu/+source/pam/+bug/337770.

Good job.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.