Red Hat Bugzilla – Bug 64836
/etc/cron.daily/makewhatis.cron: 3000 lines of "zcat: stdout: broken pipe"
Last modified: 2014-01-21 17:48:03 EST
Description of Problem:
First cron job to run following RH7.2 to 7.3 upgrade resulted in 7000-line
email to root the next morning complaining about "zcat: stdout: broken pipe"
Dunno how reproducible it is yet: only been upgraded for long enough for
one cron job :) I just did the upgrade (slightly non-standard way, but
nothing extreme) and left the box on overnight.
From: firstname.lastname@example.org (Cron Daemon)
Date: Mon, 13 May 2002 04:02:09 +0100
zcat: stdout: Broken pipe
zcat: stdout: Broken pipe
(repeat until email is 7000 lines long (including the blanks)
None of the error messages.
Weird. Just ran makewhatis by hand and it appears to have worked perfectly
Although now I am wondering why the only man page I have for it is in
Italian :) Should I close this, since makewhatis is happy now, and reopen
that as a separate bug?
I too have sometimes problems with "gzip: stdout: broken pipe" (gzip: stdout:
It occurs when using tar (and maybe once with localedef).
If I try to find the error it suddenly disappears until the next time .... ???
(redhat 7.3 both with kernel 2.4.18-3 and -4)
Same error reappeared in my root email today:
0 1 May 19 root ( 15) LogWatch for aloss
-> 0 2 May 19 Cron Daemon (6992) Cron <root@aloss> run-parts /etc/cron
Contents of the long one are as described in my original comment. Don't think
I'll close it yet after all :)
Not reproducable here...
By any chance, are there any dangling symlinks in your man directories?
Assuming that "find /usr/share/man -type d | xargs symlinks" is the
correct way to find out: no. Bunch of "absolute" links to /etc/alternatives/
and that's it.
Bero - what I think is happening is this
Some of the time cron is running with signal(SIGPIPE, SIG_IGN). The getline code
is not consuming the entire input. In normal situations this causes zcat to die
off. IFF sigpipe is masked it causes zcat to spew errors rather than die before
it can complain.
I'm not seeing this over the past few revs. Considering this as well
as the sig masking issue, I am closing as WORKSFORME for current releases.
This problem just (re-?)appeared on my RHEL 3 machine in the daily makewhatis
cronjob. It's not easily reproducible -- it may happen randomly or (more likely)
results from some race condition that hasn't been addressed. Has anyone any insight
on what might be causing this problem? Is it signal masking in cron, premature pipe
closing by cron/makewhatis, ...?
*** Bug 132437 has been marked as a duplicate of this bug. ***
Seeing the same problem, usually in the weekly cron makewhatis.
Well I guess this is because makewhatis.cron exists in the daily cron
and in the weekly cron.
I've one machine with this problem this other without. The difference
? The problematic machine runs webalizer in daily, so makewhatis
launches later and is probably launched when weekly kicks in.
/etc/crontab (for both machines)
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly
ls -1 /etc/cron.daily/
ls -1 /etc/cron.daily/
So on the problematic machine the webalizer script slow down the
A workaround is to change /etc/crontab to run montly later or make
sure that makewhatis is launched earlier (by using a file name like
00-makewhatis.cron). Of course this is not an absolute fix.
makewhatis should use it's lock to delay its start.
1.5o1 should have a re-prioritized cron jobs. makewhatis can't really
use logwatchs locks-- the newest vixie-cron seems to fix this p@roblem
OK, I started to get this problem - and I fixed.
I have two identical Dell boxes here running RHEL ES 3 fully up2dated.
Six weeks ago (end of Sept, 2004), box 'b' started to mail me the
'zcat: stdout: Broken pipe' every week. Box 'a' was unaffected.
I really didn't do anything to cause this, but thinking I remembered I
did up2date vixie-cron in the near past.
On friday last (12th Nov. 2004) I first wondered if it was zcat, so
removed and reinstalled. Running makewhatis from cron proved no. So
I then removed and reinstalled vixie-cron and crontabs:
1068 rpm -qa cron
1069 rpm -qa | grep cron
1070 rpm -e --nodeps vixie-cron-3.0.1-75.1
1071 rpm -e --nodeps crontabs-1.10-5
1072 up2date cron
1073 up2date crontabs
1074 up2date vixie-cron
And this weekend, no 'zcat: stdout: Broken pipe' mail in root mailbox
:) It appears to be working OK again.
Hey Nick, I just did what you suggested, I will wait until next
weekend to see the results. Is there any way to test this out
sooner, like ./makewhatis.cron in the cron.weekly directory??
Thanks for posting.
I've had this problem for the last couple of weeks on FC3,
reinstalling vixie-cron and crontabs has fixed it. But how?
rpm -e --nodeps vixie-cron-4.1-20_FC3 crontabs-1.10-7
yum install crontabs vixie-cron
service cron start
I tested by running run-parts cron.weekly from cron before and after
the reinstall -- I got the broken pipe errors before but not after.
*** Bug 146849 has been marked as a duplicate of this bug. ***
Fixed in RHEL3 U4.
Great. But what was the cause/fix?
We're still seeing these messages from cron.weekly on the four
gnome.org RHEL3 servers, and they're on RHN and all up2date.
A colleague of mine found the cause of the problem, at least on our boxes. We do
several things with cron, some of which cause load on central servers. For this
reason, we change the cron times randomly to spread the load. In some cases,
this causes cron.daily and cron.weekly to overlap. Since makewhatis exists as
both daily or weekly cron jobs, they too will sometimes overlap. Makewhatis has
a primitive locking mechanism which causes this error when two instances of it
are run simultanously.
Check if this applies to you. We simply pipe the output of makewhatis to
/dev/null to fix the problem at our site.
I updated to RHEL3 U5 using up2date last week, and I received the excessive
"zcat: stdout: broken pipe" lines from cron.weekly this morning. Was the fixe in
RHEL U4 reported in comment #19 reversed in U5?
I have seen broken pipe error in other cron jobs as well. One of my cron fails
while passing sort stdout to head stdin. It runs fine interactively and even
as cron on RH9. What has been suggested so far are only temporary fixes which
will reduce the frequency or delay the observation of recurrence, and thus the
> I have seen broken pipe error in other cron jobs as well.
Most likely what you are seeing is a reader closing that pipe, as it got
everything which was there, but a notification to a writer lost somewhere
when running from cron. I am not sure why this happens but most likely this
is harmless and you can simply redirect stderr to /dev/null on such occasions.
See last remarks in a lengthy discussion in bug 146849 (the same issue
but reopened for FC). Yes, it would likely be better not to get in such
situations if only possible.
This issue notwithstanding 'makewhatis' script seems to be riddled with
problems - at least in FC.
It hits many RHEL3 system after upgrading from U4 to U5.
Installed: man-1.5k-10 vixie-cron-3.0.1-76_EL3 crontabs-1.10-5
Looks like the bug isn't still really fixed, so it should be reopened.
Same as comment #25. I'll see this as results from cron.daily and cron.weekly.
Please reopen this ticket.
Same here. Annoying!
Created attachment 116226 [details]
This patch should fix this man problem.
Can you please test it?
SRPM containing this patch is available:
That patch in comment #29 is just hiding the issue. Wouldn't it be better to
find the root cause and fix it there?
The root cause of this bug is zcat and its behaviour.
In makewhatis script there is used pipe - zcat command gives its output to
getline commands. The problem occurs if zcat does not read whole file and
makewhatis does not need the other part of this file and closes this pipe. Then
zcat creates warring message "zcat: stdout: Broken pipe". The patch n comment
#29 deletes these messages.
Could anybody test this version?
Thanks for the clarification. I've built the package and installed it on one of
my machines. I won't know for a week or so if this clears the issue.
Looks like it's working. The one non-critical server I have installed this on
hasn't reported any zcat errors. Man pages are still working fine.
Seeing the problem on both a box running RHEL 3 with all updates and a box
running WhiteBox Linux 3 (also current on updates). I do not see the problem on
either of two systems running Fedora Core 4 (one was an upgrade from FC 3 and
the other a clean install). Diffing the two /usr/sbin/makewhatis files
indictaes that there was a significant re-write of the file from RHEL 3 to FC 4.
Was the patch applied to the FC 4 code base? Or is a different method being used?
There are several code base patches. One of them fix this problem for fc4. This
fc4 patch and proposed patch mentioned in comment 29 are quite similar. Please
can you test this patch or src.rpm (comment 30)?
Thank Mark for his tests.
Running with the patch now. Will apply the full source rpm after verifying that
the patch works.
With the patch applied, I get:
about to enter /usr/share/man
I'll look into how to build the source from comment #30.
it looks like your /etc/cron.weekly/makewhatis.cron file contains
-v option in makewhatis command line (original version contains olny option -w).
Could you check whether there is this option or attach your
Please could you write whether this fix your problem.
Built and installed man-1.5k-12.rhel3.test.src.rpm on both a system running
White Box Linux (see comment #39) and a loaner system from where I work (Dell PE
350) running RHEL 3. I left the -v option in place on the WB box so I would
know that makewhatis ran while the loaner from where I work just got the rpm
installed. Both systems worked correctly with the WB box giving me the "same"
output as before and no output at all from the box (running without the -v).
Both systems are current on updates.
If you think it is of interest, I'd be comfortable puttting the patched rpm in
place on my test boxes at work. These are a variety of Dell PE servers running
Installed the patched rpm on several Dell PE 1750s, a Dell PE 650, a Dell 1650
and another Dell 350 all runnin RHEL 3. If I remember correctly, all systems
are current on updates except the 650.
Was this patch applied to RHEL 4? I will probably be puting RHEL 4 on at least
some of these boxes over the next few weeks.
The next update for RHEL 3 is due out pretty soon. Will the updated RPMs be
This bug has not been reported against RHEL4 yet. I don't know whether there is
any RHEL4 system affected with this bug. If there is RHEL4 affected with it,
create bug reported against RHEL4 please.
Marc, this bug will not be fixed in RHEL3U6 yet.
>> This bug has not been reported against RHEL4 yet. <<
Please consider this a RHEL 4 report.
zcat: stdout: Broken pipe
(In reply to comment #46)
I have it, too, under RHEL4. Got the line 1822 times one week, 1941 times the next week.
I'm also still seeing this on many RHEL4u3 systems.
Adding the 2>/dev/null to silence the error as suggested above can be trivially
added to the man-1.5m2-i18n_makewhatis.patch already included in the latest man
package from RHEL4 (man-1.5o1-9).
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 the 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.
The advisory only links to packages for RHEL3, whereas I'm definitely seeing
it also on some RHEL4 systems (and am not the one one, from other comments
above). Is a similar ERRATA planned for RHEL4?
Please can you attach your messages relevant to RHEL4 to bug 170402 (it is RHEL4
version of this bug). In 170402 bug report there is a proposed patch for RHEL4
man package (there is add 2>/dev/null as it is mentioned in comment #53) and the
bug is in the state assigned now.