Bug 988537
| Summary: | cupsd can't generate core files | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Bryan Mason <bmason> |
| Component: | cups | Assignee: | Tim Waugh <twaugh> |
| Status: | CLOSED NOTABUG | QA Contact: | qe-baseos-daemons |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.4 | ||
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-07-25 22:44:08 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. |
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): cups-1.4.2 How reproducible: 100% 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 /etc/rc.d/init.d/cups: 48 [ -f /etc/sysconfig/cups ] && . /etc/sysconfig/cups So the least invasive solution may be to use the sysconfig file.