Bug 64836 - /etc/cron.daily/makewhatis.cron: 3000 lines of "zcat: stdout: broken pipe"
Summary: /etc/cron.daily/makewhatis.cron: 3000 lines of "zcat: stdout: broken pipe"
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: man (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Ivana Varekova
QA Contact: Ben Levenson
: 132437 (view as bug list)
Depends On:
Blocks: 168424
TreeView+ depends on / blocked
Reported: 2002-05-13 11:00 UTC by Telsa Gwynne
Modified: 2014-01-21 22:48 UTC (History)
38 users (show)

Fixed In Version: RHBA-2006-0010
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-15 15:50:43 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
This patch should fix this man problem. (465 bytes, patch)
2005-07-01 08:09 UTC, Ivana Varekova
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2006:0010 qe-ready SHIPPED_LIVE man bug fix update 2006-03-14 05:00:00 UTC

Description Telsa Gwynne 2002-05-13 11:00:29 UTC
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.

Actual Results:

From: root@aloss.ukuu.org.uk (Cron Daemon)
To: root@aloss.ukuu.org.uk
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)

Expected Results:

None of the error messages.

Comment 1 Telsa Gwynne 2002-05-13 13:40:57 UTC
Weird. Just ran makewhatis by hand and it appears to have worked perfectly
this time.

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?

Comment 2 Herbert Gasiorowski 2002-05-16 13:58:00 UTC
I too have sometimes problems with "gzip: stdout: broken pipe" (gzip: stdout:
Input/output error)!

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)

Comment 3 Telsa Gwynne 2002-05-19 07:12:23 UTC
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 :)

Comment 4 Bernhard Rosenkraenzer 2002-05-19 16:25:04 UTC
Not reproducable here... 
By any chance, are there any dangling symlinks in your man directories?

Comment 5 Telsa Gwynne 2002-05-20 15:43:49 UTC
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.

Comment 6 Alan Cox 2002-05-26 17:34:48 UTC
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.

Comment 7 Eido Inoue 2004-02-19 17:05:43 UTC
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.

Comment 8 Brian Carp 2004-10-08 16:14:47 UTC
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, ...?

Comment 9 Eido Inoue 2004-10-08 20:07:18 UTC
*** Bug 132437 has been marked as a duplicate of this bug. ***

Comment 12 Mark Komarinski 2004-11-01 15:13:58 UTC
Seeing the same problem, usually in the weekly cron makewhatis.

Comment 13 Philippe Jandot 2004-11-02 13:20:08 UTC
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

Problematic machine:

ls -1 /etc/cron.daily/

Working machine:

ls -1 /etc/cron.daily/

So on the problematic machine the webalizer script slow down the
makewhatis launch.

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.

Comment 14 Eido Inoue 2004-11-10 01:20:58 UTC
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

Comment 15 Nick Warne 2004-11-15 14:28:29 UTC
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.


Comment 16 Billy Jones 2004-11-15 15:07:25 UTC
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.

Comment 17 Steve Woodcock 2005-01-30 14:56:57 UTC
I've had this problem for the last couple of weeks on FC3,
reinstalling vixie-cron and crontabs has fixed it. But how?

I did:

  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.

Comment 18 Eido Inoue 2005-02-02 18:51:55 UTC
*** Bug 146849 has been marked as a duplicate of this bug. ***

Comment 19 Bastien Nocera 2005-02-04 11:51:28 UTC
Fixed in RHEL3 U4.

Comment 20 Need Real Name 2005-02-27 12:26:41 UTC
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.

Comment 21 Trond H. Amundsen 2005-03-21 10:22:44 UTC
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.

Comment 22 Gene Willacker 2005-05-22 14:31:59 UTC
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?

Comment 23 Vinod Gupta 2005-05-29 15:10:48 UTC
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 

Comment 24 Michal Jaegermann 2005-05-29 15:54:42 UTC
> 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.

Comment 25 Peter Bieringer 2005-05-31 09:13:57 UTC
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.

Comment 26 Mark Komarinski 2005-06-06 14:54:49 UTC
Same as comment #25.   I'll see this as results from cron.daily and cron.weekly.
 Please reopen this ticket.

Comment 27 Robert Berlinger 2005-06-06 15:14:44 UTC
Same here.  Annoying!

Comment 29 Ivana Varekova 2005-07-01 08:09:19 UTC
Created attachment 116226 [details]
This patch should fix this man problem. 

Can you please test it?

Comment 30 Ivana Varekova 2005-07-01 08:43:10 UTC
SRPM containing this patch is available: 

Comment 31 Mark Komarinski 2005-07-01 13:54:52 UTC
That patch in comment #29 is just hiding the issue.  Wouldn't it be better to
find the root cause and fix it there?

Comment 32 Ivana Varekova 2005-07-07 12:12:49 UTC
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? 

Comment 33 Mark Komarinski 2005-07-07 12:19:07 UTC
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.

Comment 35 Mark Komarinski 2005-07-18 14:42:03 UTC
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.

Comment 36 Dave Miller 2005-07-24 15:44:57 UTC
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?

Comment 37 Ivana Varekova 2005-07-25 11:58:16 UTC
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.
Ivana Varekova

Comment 38 Dave Miller 2005-07-25 12:19:45 UTC
Running with the patch now.  Will apply the full source rpm after verifying that
the patch works.

Comment 39 Dave Miller 2005-07-31 15:16:18 UTC
With the patch applied, I get:


about to enter /usr/share/man
adding ./uuidgen.1.gz
adding ./chattr.1.gz
adding ./lsattr.1.gz
adding ./jpegtran.1.gz
adding ./xmlwf.1.gz
adding ./cjpeg.1.gz
adding ./djpeg.1.gz
adding ./dnsdomainname.1.gz
adding ./rdjpgcom.1.gz
adding ./wrjpgcom.1.gz
adding ./mktemp.1.gz
adding ./nisdomainname.1.gz
adding ./domainname.1.gz
adding ./hostname.1.gz
adding ./newaliases.sendmail.1.gz
adding ./ypdomainname.1.gz

I'll look into how to build the source from comment #30.

Comment 40 Ivana Varekova 2005-08-01 08:26:45 UTC
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
/etc/cron.weekly/makewhatis.cron file. 
Please could you write whether this fix your problem.
Ivana Varekova 

Comment 42 Dave Miller 2005-08-14 15:48:21 UTC
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

Comment 43 Dave Miller 2005-08-24 03:45:06 UTC
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.

Comment 44 Marc Wallman 2005-08-30 15:26:15 UTC
The next update for RHEL 3 is due out pretty soon. Will the updated RPMs be
rolled in?

Comment 45 Ivana Varekova 2005-09-05 08:12:55 UTC
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. 

Comment 46 Steven Estrada 2005-09-11 11:52:25 UTC
>> This bug has not been reported against RHEL4 yet. <<

Please consider this a RHEL 4 report.


zcat: stdout: Broken pipe


Comment 48 Jonathan Pool 2005-10-25 22:32:25 UTC
(In reply to comment #46)

I have it, too, under RHEL4. Got the line 1822 times one week, 1941 times the next week.

Comment 49 Jonathan Pool 2005-10-25 22:34:03 UTC
(In reply to comment #46)

I have it, too, under RHEL4. Got the line 1822 times one week, 1941 times the next week.

Comment 53 Matthias Saou 2006-03-13 11:35:13 UTC
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).

Comment 54 Red Hat Bugzilla 2006-03-15 15:50:43 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 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.


Comment 55 Matthias Saou 2006-03-15 16:13:29 UTC
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?

Comment 56 Ivana Varekova 2006-03-16 08:33:19 UTC
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. 

Note You need to log in before you can comment on or make changes to this bug.