Bug 988537 - cupsd can't generate core files
cupsd can't generate core files
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: cups (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Tim Waugh
Depends On:
  Show dependency treegraph
Reported: 2013-07-25 15:20 EDT by Bryan Mason
Modified: 2013-07-25 18:44 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-07-25 18:44:08 EDT
Type: Bug
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 Bryan Mason 2013-07-25 15:20:11 EDT
Description of problem:

    It is difficult to debug cupsd segfaults since cupsd sets the
    corefile limit to 0 on startup.

Version-Release number of selected component (if applicable):


How reproducible:

Steps to Reproduce:

    1. Modify initscripts to allow core files.
    2. Wait for cupsd to segfault for some reason.

Actual results:

    Core file should be created.

Expected results:

    No core file.

Additional info:

    main() in scheduler/main.c does this:

    456     getrlimit(RLIMIT_CORE, &limit);
    457     limit.rlim_cur = 0;
    458     setrlimit(RLIMIT_CORE, &limit);

    after processing command-line parameters, but before reading
    cupsd.conf so it seems like the only way to conditionally stop
    this code from executing is to use a command-line option or an
    environment variable set in /etc/sysconfig/cups.  We don't ship a
    CUPS sysconfig file currently, but there is support for it in

     48 [ -f /etc/sysconfig/cups ] && . /etc/sysconfig/cups

    So the least invasive solution may be to use the sysconfig file.
Comment 2 Bryan Mason 2013-07-25 17:52:40 EDT
Well, never mind maybe.  It appears that abrt does something to work around the zero-size ulimit for corefiles:

[root@rhel64-test ~]# service cups status 
cupsd (pid  23710) is running...

[root@rhel64-test ~]# kill -SEGV 23710

[root@rhel64-test ~]# tail /var/log/messages
Jul 25 14:43:43 rhel64-test-hex abrtd: Directory 'ccpp-2013-07-25-14:43:43-23710' creation detected
Jul 25 14:43:43 rhel64-test-hex abrt[23807]: Saved core dump of pid 23710 (/usr/sbin/cupsd) to /var/spool/abrt/ccpp-2013-07-25-14:43:43-23710 (1347584 bytes)

[root@rhel64-test ~]# file '/var/spool/abrt/ccpp-2013-07-25-14:43:43-23710/coredump' 
/var/spool/abrt/ccpp-2013-07-25-14:43:43-23710/coredump: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from 'cupsd -C /etc/cups/cupsd.conf'

[root@rhel64-test ~]# ll '/var/spool/abrt/ccpp-2013-07-25-14:43:43-23710/coredump'
-rw-r-----. 1 abrt root 1347584 Jul 25 14:43 /var/spool/abrt/ccpp-2013-07-25-14:43:43-23710/coredump

And after installing the appropriate -debuginfo packages, gdb generates a good backtrace after loading that corefile.

So it would seem as long as the customer is running abrt, cupsd will generate a core file, even though it sets the corefile limit to 0.  

I'm wondering if maybe the ulimit on core files has to do with actual file size, and since the kernel isn't generating a *file* for cupsd -- it's actually writing the core data to a pipe which is read by abrt-ccpp -- then the corefile ulimit doesn't apply.

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