Bug 649674

Hello, 
please could you edit /etc/cron.daily/man-db.cron
and add to mandb option --debug and paste here cron output:
----------------------------
--- ./man-db.crondaily.pom	2010-10-18 12:12:28.000000000 +0200
+++ ./man-db.crondaily	2010-11-05 12:20:25.000000000 +0100
@@ -20,6 +20,6 @@ LOCKFILE=/var/lock/man-db.lock
 trap "{ rm -f $LOCKFILE ; exit 255; }" EXIT
 touch $LOCKFILE
 # create/update the mandb database
-mandb $OPTS
+mandb --debug $OPTS
 
 exit 0
---------------------------

I tried a few things over the last week:

1. Setting OPTS=--debug in /etc/sysconfig/man-db

I got lots of output from cron as a result but none of the reported errors, despite gzip use being evident from the output.

2. Editing /etc/cron.daily/man-db.cron to redirect stdout and stderr to a temp file

Similar result to the first effort (output in temp file)

I then reverted to the out of the box configuration and the errors are back.

Strangely, I'm only seeing this on one of the 4 F14 boxes (3 real, one virtual - the problem box is real) I have.

If man-db was rebuilt to use zlib, it then wouldn't run gzip, so probably wouldn't have this exact issue.

I was going to request adding BuildRequires: zlib-devel to make man-db faster, but in my testing it didn't seem to be significantly faster. The debian and ubuntu man-db packages appear to be built with zlib support.

This issue looks similar to Bug #64836 and Bug #170402; maybe a similar fix/workaround could be applied?

While I'm not entirely unwilling to work around this in man-db upstream by forcing SIGPIPE back to its default disposition, the root cause is bug #475106.  Perhaps somebody could reopen that and put it somewhere where it might get fixed rather than triaged into oblivion?

Hello, there can be redirected the output to /dev/null 
(see https://bugzilla.redhat.com/show_bug.cgi?id=64836), but it helpful to have the debug output described in comment 1. 
I will ask vixie-cron maintainer about 475106.

From my point of view the best solution is to patch vixie-cron package in this case (see https://bugzilla.redhat.com/show_bug.cgi?id=475106 for the bug description). Please Marcela can you look at it?

I have been seeing the same issue and have done a little digging: The problem may not be with cronie itself but whatever is used to run the batch scripts.

I added the line 'cat /proc/self/status' to /etc/cron.daily/man-db.cron and saw "SigIgn: 0000000001001000". Looks like SigPipe is ignored at that point.

Then I added a job to /etc/crontab - '* * * * * root cat /proc/self/status' and saw "SigIgn: 0000000000000000". So, no signals ignored by cronie or it's job execution code.

I run batches using a Python script that handles pre/daily/weekly/monthly/post etc. and found a cure for my issues: The Python subprocess.Popen() call that I use to execute jobs ignores SigPipe, presumably to keep the noise from sub-precesses down. I added a "preexec_fn" to the call that resets SigPipe: "signal.signal(signal.SIGPIPE, signal.SIG_DFL)". The result is no more 'gzip: stdout: Broken pipe' messages from the batch runs.

So, does the standard configuration (/usr/bin/run-parts) do the same kind of thing? Apparently not...

mkdir /etc/cron.test
cat >/etc/cron.test/status <<EOF
#!/bin/sh
cat /proc/self/status
EOF
chmod +x /etc/cron.test/status
/usr/bin/run-parts /etc/cron.test
...
SigIgn:	0000000000000000
...

P.S. cronie-1.4.5-4.fc14.x86_64

DaveG, regarding Python's handling of SIGPIPE, you may find it useful to read http://bugs.python.org/issue1652.  In short, the fact that you had to use that preexec_fn was a bug in Python, fixed in Python 3.2.

Thanks for the heads-up, Colin. Still using Python 2.7.
Just wondering if the same kind of issue is in play for this bug? cronie itself looks OK but what about anacron+run-parts? I see exactly the same symptoms and resetting SigPipe fixed it for me. My scripts replace anacron so I can't easily check.

It does not seem to happen here. I've tried to update cronie with yum on my F14 VM and the SIGPIPE is not ignored in the crond process:

ps axu | grep crond
root     12922  5.1  0.1 112540  1312 ?        Ss   09:17   0:00 crond

cat /proc/12922/status | grep SigIgn
SigIgn:	0000000001000000

I am not sure why the 25th signal is ignored but SIGPIPE is not.

So I do not think it is related to bug 475106
Also there is no modification of SIGPIPE ignore status neither in crond nor in the anacron sources in cronie.

Reporter, can you still reproduce it on the fully updated F14 system?

I haven't seen this issue for a few months now.

Tomas, it may depend on the context in which cron was last restarted.  For instance, gnome-session still (over ten years after mailing list discussions I've found on the subject!) leaves SIGPIPE ignored for its child processes.  These might include terminal windows where you might for example run an upgrade that causes cron to be restarted.

Also, on noticing this gnome-session behaviour, I got fed up and decided to just work around this in man-db upstream:

Wed Mar  2 11:12:13 GMT 2011  Colin Watson  <cjwatson>

        * src/mandb.c (main): Reset SIGPIPE to SIG_DFL on startup, to avoid
          noisy output in the event that mandb was started from a context
          where SIGPIPE was ignored (e.g. Fedora bug #649674).
        * NEWS: Document this.

Of course, that doesn't mean it stops being a bug anywhere else.  Ignored-SIGPIPE bugs are pernicious.

OK, but then it is a question who should clear up the SIGPIPE ignore action when it is set.

By the way neither bash running from gnome-terminal nor from lxterminal seems to have the SIGPIPE set to ignore although both gnome-terminal and lxterminal have it set. So apparently lxterminal/gnome-terminal resets the SIGPIPE action.

I also tried to upgrade cronie with PackageKit and although the packagekitd had SIGPIPE ignored the crond which was started during the upgrade does not. So I am really out of ideas where the ignored SIGPIPE is coming from.

To me it would seem to be logical to clear it in the /sbin/service or in the initscript daemon function, however bash does not allow clearing ignored signals in scripts when they were ignored at the bash startup.

So perhaps really the cron should clear SIGPIPE action when it daemonizes itself, just to be sure that the signal is not ignored in the children.

Yes, gnome-terminal certainly does.  I noticed it because pterm doesn't.

Fixed in upstream ee4cbe7659ede3f61db18cc922ee0e27268a8579. It will be in cronie-1.4.7.

cronie-1.4.7-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/cronie-1.4.7-1.fc14

cronie-1.4.7-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.