988537 – cupsd can't generate core files

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 988537 - cupsd can't generate core files

Summary: cupsd can't generate core files

Keywords:
Status:	CLOSED NOTABUG
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	cups
Sub Component:
Version:	6.4
Hardware:	All
OS:	Linux
Priority:	medium
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	Tim Waugh
QA Contact:	qe-baseos-daemons
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2013-07-25 19:20 UTC by Bryan Mason
Modified:	2013-07-25 22:44 UTC (History)
CC List:	0 users
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2013-07-25 22:44:08 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Description Bryan Mason 2013-07-25 19:20:11 UTC

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.

Comment 2 Bryan Mason 2013-07-25 21:52:40 UTC

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.