Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 4 product line. The current stable release is 4.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 491637

Summary: possible deadlock in ctime() called from signal handler
Product: Red Hat Enterprise Linux 4 Reporter: Tomas Smetana <tsmetana>
Component: sysklogdAssignee: Peter Vrabec <pvrabec>
Status: CLOSED ERRATA QA Contact: BaseOS QE <qe-baseos-auto>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 4.6CC: fnadge, jwest, ksrot, moshiro, ohudlick, sgrubb
Target Milestone: rcKeywords: ZStream
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Cause: In case a message is being logged, syslogd calls ctime() which locks a futex. If at the same moment also a MARK message alarm occurs, the ctime() is called again from the signal handler and the futex is never released. Consequence: deadlock Fix: syslogd will no longer generate any I/O nor call ctime() within the signal handler Result: no deadlock
 Story Points: ---
Clone Of: Environment:
Last Closed: 2011-02-16 14:07:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 485811, 615340    
Attachments:
Description Flags
Proposed patch none

Description Tomas Smetana 2009-03-23 13:14:47 UTC 
Description of problem:
The syslogd daemon can deadlock in ctime() call when set up to output MARK messages:  In case a message is being logged, syslogd calls ctime() which locks a futex.  If at the same moment also a MARK message alarm occurs, the ctime() is called again from the signal handler and the futex is never released which leads to a deadlock.

Version-Release number of selected component (if applicable):
sysklogd-1.4.1-26_EL

How reproducible:
Sometimes

Steps to Reproduce:
1. Configure syslogd to output the MARK messages (e.g. by setting SYSLOGD_OPTIONS="-m1" in /etc/sysconfig/syslog)
2. Let the system run
  
Actual results:
syslogd hangs in ctime() call sometimes

Expected results:
no hang

Additional info:
This is a known problem which was fixed in sysklogd-1.4.1-28 (and therefore is not present in RHEL-5) -- see bug #152319.
Comment 1 Tomas Smetana 2009-03-23 13:16:22 UTC 
Created attachment 336287 [details]
Proposed patch

Merge of patches for bug #152319 and bug #158205 (the former contained a regression).
Comment 14 Florian Nadge 2011-01-19 15:42:03 UTC 
Please be so kind and add a few key words to the technical note of this
bugzilla entry using the following structure:

Cause:

Consequence:

Fix:

Result:


For details, see:
https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes

Thanks
Comment 15 Florian Nadge 2011-01-19 15:42:04 UTC 
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause:

Consequence:

Fix:

Result:
Comment 16 Peter Vrabec 2011-01-20 15:47:12 UTC 
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,7 +1,10 @@
-Cause:
+Cause: In case a message is being logged, syslogd calls ctime() which locks a futex.  If at the same moment also a MARK message alarm occurs, the ctime() is called again from the signal handler and the futex is never released.
 
 Consequence:
+deadlock
 
 Fix:
+syslogd will no longer generate any I/O  nor call ctime() within the signal handler
 
-Result:+Result:
+no deadlock
Comment 17 errata-xmlrpc 2011-02-16 14:07:12 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0225.html