Red Hat Bugzilla – Bug 988537
cupsd can't generate core files
Last modified: 2013-07-25 18:44:08 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):
Steps to Reproduce:
1. Modify initscripts to allow core files.
2. Wait for cupsd to segfault for some reason.
Core file should be created.
No core file.
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.
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: 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.