Bug 163484

Summary: crond doesn't initialise SIGPIPE handler
Product: Red Hat Enterprise Linux 3 Reporter: Kjetil T. Homme <kjetilho>
Component: vixie-cronAssignee: Marcela Mašláňová <mmaslano>
Status: CLOSED DEFERRED QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: jvdias, t.h.amundsen
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-10-30 09:49:06 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:

Description Kjetil T. Homme 2005-07-18 08:32:20 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513

Description of problem:
crond trusts the signal settings for SIGPIPE can be used when spawning its own children.  this is not a safe assumption, it needs to explicitly set it to SIG_DFL before launching child processes.  see bug 146849 and bug 163483.


Version-Release number of selected component (if applicable):
vixie-cron-3.0.1-76_EL3

How reproducible:
Always

Steps to Reproduce:
compile this small program:

#include <stdio.h>
#include <signal.h>

int main() {
        sig_t old = signal(SIGPIPE, SIG_DFL);
        if (old == SIG_DFL) puts("SIG_DFL");
        else if (old == SIG_IGN) puts("SIG_IGN");
        else puts("UNKNOWN");
        return 0;
}

now as root:

trap "" PIPE
/etc/init.d/crond stop
/etc/init.d/crond start

install a crontab running the above program, and direct its output somewhere.

Actual Results:  the log file contains SIG_IGN

Expected Results:  crond should reset the SIGPIPE handler to SIG_DFL.


Additional info:
Comment 1 Jason Vas Dias 2005-07-18 13:59:33 UTC 
I've read bug 146849 and bug 163483 as you suggested. 

The root cause of the problem seems to be RPM running its %post scripts
with "trap '' PIPE":
"  in ./rpmdb/rpmdb.c, SIGPIPE is set to be ignored before opening the RPM
   database.  it is not reset until the database has been closed.  in the 
   meantime, some packages will spawn scripts to do pre- or post-install, 
   and these will inherit the SIGPIPE setting.  in our case, this is crond,
   which in turn is passing it on to its children.
"
Because RPM is running 'service crond restart' after an vixie-cron update
with SIGPIPE set to SIG_IGN, the problems in bug 146849 occur unless 
vixie-cron is restarted normally - correct ?

I don't think vixie-cron should disable all inherited signal handlers by 
default - perhaps someone might want it to inherit a signal handler. 

If vixie-cron should reset SIGPIPE handling to SIG_DFL, it should do so 
for EVERY signal that it does not explicitly set a handler for, and so 
should every process that may be run from an RPM %post .

Yet processes are meant to be able to assume that signal handlers are at
SIG_DFL on start-up .

So I think we should fix RPM not to run %post scripts with 'trap'-ed signals
rather than patching every process that may be run from a %post script to 
restore signal handling to defaults.
Comment 2 Kjetil T. Homme 2005-07-18 14:12:50 UTC 
putting the blame on RPM was a bit rash, I can't reproduce it.  rhnsd is a more
likely culprit.

but I think cron has a special position, and most people expect the environment
it gives new processes to be untainted.  e.g., I would definitely call it a bug
if it inherited the $PATH root had when starting the daemon.  by environment I
mean rlimits, signal handlers and of course environment variables.  (I remember
starting inetd with a full environment 10 years ago.  telnetd didn't clear
$LOGNAME, and they were very confused when various applications identified them
as _me_ :-)

I understand your position, but I think by the principle of least surprise, the
behaviour of crond should be constant, regardless of the circumstances of
invocation.
Comment 3 Jeff Johnson 2005-10-25 23:40:53 UTC 
rpm traps sigpipe in order to gracefully close a rpmdb when less is executed early in
    rpm -qa | less

crond needs to be fixed, because its not only rpm that can do "service crond restart"
with signals in non-default settings, any command run by root will show the same
symptoms if signal handlers are changed.
Comment 4 Marcela Mašláňová 2006-10-30 09:49:06 UTC 
This problem will be resolved in a future major release of Red Hat Enterprise 
Linux. Red Hat does not currently plan to provide a resolution for this in a 
Red Hat Enterprise Linux update for currently deployed systems.