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" man-1.5j-5 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.org.uk (Cron Daemon) To: root.org.uk Date: Mon, 13 May 2002 04:02:09 +0100 /etc/cron.daily/makewhatis.cron: 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.
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?
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)
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 Problematic machine: ls -1 /etc/cron.daily/ 00-logwatch 00webalizer certwatch logrotate makewhatis.cron [...] Working machine: ls -1 /etc/cron.daily/ 00-logwatch certwatch logrotate makewhatis.cron [...] 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.
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 also.
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. Nick
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? 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.
*** 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 sulution.
> 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: http://people.redhat.com/varekova/man-1.5k-12.rhel3.test.src.rpm
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. Ivana Varekova
Running with the patch now. Will apply the full source rpm after verifying that the patch works.
With the patch applied, I get: /etc/cron.weekly/makewhatis.cron: 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.
Hello, 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
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 RHEL 3.
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 rolled in?
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. /etc/cron.weekly/00-makewhatis.cron: zcat: stdout: Broken pipe <snip>
(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. http://rhn.redhat.com/errata/RHBA-2006-0010.html
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.