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:
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.
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.
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.
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.