Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 604455 - Displaying long man pages with ksh or csh results in "gzip: stdout: Broken pipe" messages
Displaying long man pages with ksh or csh results in "gzip: stdout: Broken pi...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: man (Show other bugs)
6.0
All Linux
low Severity low
: rc
: ---
Assigned To: Peter Schiffer
qe-baseos-daemons
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-15 18:59 EDT by Quentin Barnes
Modified: 2011-11-24 16:22 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-11-24 16:22:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace of the failure (17.79 KB, application/octet-stream)
2010-06-21 09:26 EDT, Ondrej Vasik
no flags Details
proposed patch (1.51 KB, patch)
2010-12-06 07:42 EST, Jan Görig
no flags Details | Diff

  None (edit)
Description Quentin Barnes 2010-06-15 18:59:13 EDT
Description of problem:
The man command when displaying long man pages will give one or more "gzip: stdout: Broken pipe" when starting up to stderr.  It doesn't matter what pager the user has set.  "Short" man pages do not produce the error.

This problem only appeared when using csh or ksh.  I did not see it happen when using bash or sh.


Version-Release number of selected component (if applicable):
ksh-20091224-1.el6.x86_64



How reproducible: 100%


Steps to Reproduce:
1. Enter a "/bin/ksh" or "/bin/csh" interactive shell, then
2. "man zip", "man wget", or "man ksh".
3.
  
Actual results:
==============================================
$ man man
$ man ksh

gzip: stdout: Broken pipe

gzip: stdout: Broken pipe
$ man zip

gzip: stdout: Broken pipe
$ man wget

gzip: stdout: Broken pipe

gzip: stdout: Broken pipe
$ man znew
==============================================

Start up each command then "q" out of the pager.  You'll

Short man pages like man(1) and znew(1) produce no error message.

Very long man pages like ksh(1) and wget(1) produce two error messages.

Medium length man pages like zip(1) produce only one error message.


Expected results:
No error messages regardless of the length of the man page or shell used.


Additional info:
Comment 1 Quentin Barnes 2010-06-15 19:01:58 EDT
Oops, gave the RPM package for ksh (which might matter).  I meant to paste in the RPM version for man which is "man-1.6f-24.1.el6.x86_64".

And additionally, I have no problems on RHEL5.x with man and any shell.
Comment 3 RHEL Product and Program Management 2010-06-15 19:13:08 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 4 Ivana Varekova 2010-06-16 04:13:21 EDT
Hello, 
please could you test commands:

(cd "/usr/share/man" && (echo ".pl 11i"; /usr/bin/gunzip -c '/usr/share/man/man1/ksh.1.gz') | /usr/bin/gtbl | /usr/bin/nroff -c -mandoc 2>/dev/null)

(cd "/usr/share/man" && (echo ".pl 11i"; /usr/bin/gunzip -c '/usr/share/man/man1/zip.1.gz') | /usr/bin/gtbl | /usr/bin/nroff -c -mandoc 2>/dev/null)

(cd "/usr/share/man" && (echo ".pl 11i"; /usr/bin/gunzip -c '/usr/share/man/man1/wget.1.gz') | /usr/bin/gtbl | /usr/bin/nroff -c -mandoc 2>/dev/null)

and write here the result?
Comment 5 Quentin Barnes 2010-06-18 12:23:24 EDT
No problems at all running the three commands below:
=======
$ (cd "/usr/share/man" && (echo ".pl 11i"; /usr/bin/gunzip -c '/usr/share/man/man1/ksh.1.gz') | /usr/bin/gtbl | /usr/bin/nroff -c -mandoc 2>/dev/null)
KSH(1)                                                                  KSH(1)



NAME
       ksh,  rksh,  pfksh  - KornShell, a standard/restricted command and pro-
       gramming language
[...]
       It is a good idea to leave a space after the comma operator  in  arith-
       metic  expressions  to  prevent the comma from being interpreted as the
       decimal point character in certain locales.




RDS Standard              User Environment Utilities                    KSH(1)
$


$ (cd "/usr/share/man" && (echo ".pl 11i"; /usr/bin/gunzip -c '/usr/share/man/man1/zip.1.gz') | /usr/bin/gtbl | /usr/bin/nroff -c -mandoc 2>/dev/null)
ZIP(1L)                                                                ZIP(1L)



NAME
       zip, zipcloak, zipnote, zipsplit - package and compress (archive) files

[...]

$ (cd "/usr/share/man" && (echo ".pl 11i"; /usr/bin/gunzip -c '/usr/share/man/man1/wget.1.gz') | /usr/bin/gtbl | /usr/bin/nroff -c -mandoc 2>/dev/null)
WGET(1)                            GNU Wget                            WGET(1)



NAME
       Wget - The non-interactive network downloader.

SYNOPSIS
=======

I take it you're having problem reproducing the problem for
yourself?

I have my login shell set to "/bin/ksh".  I even moved my .profile
out of the way (so no ~/.profile at all) so I know my environment
isn't interfering.  I still get the "Broken pipe" error messages.

Maybe there's a shell, xterm, or psuedo tty setting that's a source
of the problem?  Still with no ~/.profile, I tried logging in on
one of the virtual terminals and still had the problem.  I logged
in via the serial port (/dev/ttyS0) and still had the problem too.
That eliminates most all of the X environment.  However, logging in
remotely from a RHEL5 with ssh did not reproduce the problem!  I
compared "stty -a" output and no real differences.  Any thoughts on
how to isolate this fault further?
Comment 6 Ondrej Vasik 2010-06-21 09:26:29 EDT
Created attachment 425625 [details]
strace of the failure

Reproducible for me with RHEL-6 beta1 and ksh as login shell - without any changes - attached strace shows SIG_PIPE error messages... however - manpage appears to be shown correctly.
Comment 7 Ivana Varekova 2010-06-22 08:04:07 EDT
The problem seems to be in some environment variables.
Now we can reproduce the problem if the user have ksh as the initial shell (if
it is switched to bash and then to ksh, the bug did not happen).
man command calls just a fork process which realise just the commands which are
in  comment 4 and which works ok. 
Reassigning to ksh.
Comment 8 Michal Hlavinka 2010-06-22 11:15:56 EDT
something rotten is here... I can reproduce this in rhel 6, but can't reproduce with the same version of ksh in rhel 5. I can also confirm that in ksh->bash->ksh everything works fine. I've checked environment variables and ulimits and there are no differences.

anyway, one interesting thing for now is that (t)csh shell and mksh shell produces the same error(bash and zsh are working):
$ useradd -s /bin/csh cshtest
$ su - cshtest -c 'man wget'
Password: 

gzip: stdout: Broken pipe

gzip: stdout: Broken pipe


and another interesting thing:
su - {csh,ksh}test -c 'man wget'
produces error if executed as ordinary user, but when executed as root, everything works
Comment 9 Michal Hlavinka 2010-06-23 05:00:41 EDT
and yet another interesting thing:

using su -c 'man wget' I can reproduce this even with BASH, so I'm not convinced this is exactly ksh's fault

$ su -c 'man wget'
Password: 

gzip: stdout: Broken pipe

gzip: stdout: Broken pipe
Comment 10 Michal Hlavinka 2010-06-23 08:27:28 EDT
In F-13 everything works fine. I've tried to rebuild all F-13 packages (man, groff, gzip, ksh) for rhel6 and problem is still reproducible
Comment 11 Michal Hlavinka 2010-06-23 10:13:00 EDT
I've compared strace of man wget and su -c 'man wget'. Seems in both cases there is SIGPIPE but only in first case error is reported:

broken: su `whoami` -c 'strace -o ~/vystupX.txt -f man wget >/dev/null'
 rt_sigaction(SIGINT, {0x402c10, [HUP INT TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, NULL, 8) = 0
 rt_sigaction(SIGHUP, {0x402c10, [HUP INT TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, NULL, 8) = 0
 rt_sigaction(SIGTERM, {0x402c10, [HUP INT TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, NULL, 8) = 0
 rt_sigaction(SIGXCPU, {0x402c10, [HUP INT TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, NULL, 8) = 0
 rt_sigaction(SIGXFSZ, {0x402c10, [HUP INT TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, NULL, 8) = 0
 open("/usr/share/man/man1/wget.1.gz", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 4
 fstat(4, {st_mode=S_IFREG|0644, st_size=28281, ...}) = 0
 read(4, ""..., 32768) = 28281
 read(4, "", 4487)                 = 0
 brk(0)                            = 0x15f7000
 brk(0x1618000)                    = 0x1618000
 write(1, "."..., 32768) = 32768
 <... read resumed> "."..., 4096) = 4096
 close(4)                          = 0
 wait4(16496,  <unfinished ...>
 write(1, "n"..., 32768) = -1 EPIPE (Broken pipe)
 --- SIGPIPE (Broken pipe) @ 0 (0) ---
 write(2, "\ngzip: ", 7)           = 7
 write(2, "stdout: Broken pipe\n", 20) = 20
 rt_sigprocmask(SIG_BLOCK, [HUP INT TERM XCPU XFSZ], [], 8) = 0
 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
 close(0)                          = 0
 close(1)                          = 0
 close(2)                          = 0
 exit_group(1)                     = ?
 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0, NULL) = 16496
 --- SIGCHLD (Child exited) @ 0 (0) ---


works: strace -o ~/vystupZ.txt -f man wget >/dev/null
 rt_sigaction(SIGINT, {0x402c10, [HUP INT PIPE TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, NULL, 8) = 0
 rt_sigaction(SIGHUP, {0x402c10, [HUP INT PIPE TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, NULL, 8) = 0
 rt_sigaction(SIGPIPE, {0x402c10, [HUP INT PIPE TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, NULL, 8) = 0
 rt_sigaction(SIGTERM, {0x402c10, [HUP INT PIPE TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, NULL, 8) = 0
 rt_sigaction(SIGXCPU, {0x402c10, [HUP INT PIPE TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, NULL, 8) = 0
 rt_sigaction(SIGXFSZ, {0x402c10, [HUP INT PIPE TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, NULL, 8) = 0
 open("/usr/share/man/man1/wget.1.gz", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 4
 fstat(4, {st_mode=S_IFREG|0644, st_size=28281, ...}) = 0
 read(4, ""..., 32768) = 28281
 read(4, "", 4487)                 = 0
 brk(0)                            = 0x21b7000
 brk(0x21d8000)                    = 0x21d8000
 write(1, "."..., 32768) = 32768
 <... read resumed> "."..., 4096) = 4096
 write(1, "n"..., 32768) = 32768
 write(1, ""..., 20775 <unfinished ...>
 close(4)                          = 0
 wait4(16577,  <unfinished ...>
 <... write resumed> )             = 4096
 --- SIGPIPE (Broken pipe) @ 0 (0) ---
 rt_sigprocmask(SIG_BLOCK, [HUP INT PIPE TERM XCPU XFSZ], [HUP INT PIPE TERM XCPU XFSZ], 8) = 0
 rt_sigprocmask(SIG_SETMASK, [HUP INT PIPE TERM XCPU XFSZ], NULL, 8) = 0
 rt_sigaction(SIGPIPE, {SIG_DFL, [PIPE], SA_RESTORER|SA_RESTART, 0x33aaa32a40}, {0x402c10, [HUP INT PIPE TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, 8) = 0
 gettid()                          = 16577
 tgkill(16577, 16577, SIGPIPE)     = 0
 rt_sigreturn(0x40c1)              = 4096
 --- SIGPIPE (Broken pipe) @ 0 (0) ---
 <... wait4 resumed> [{WIFSIGNALED(s) && WTERMSIG(s) == SIGPIPE}], 0, NULL) = 16577
 --- SIGCHLD (Child exited) @ 0 (0) ---


see "rt_sigaction(SIGPIPE,..." which is missing in broken version
Comment 12 Ondrej Vasik 2010-06-24 04:27:06 EDT
You are right, it has nothing to do with ksh itself ... 
Some related topics on internet: 
http://www.mail-archive.com/redhat-devel-list@redhat.com/msg04125.html
http://www.cygwin.com/ml/cygwin/2005-07/msg00912.html
http://www.cygwin.com/ml/cygwin/2005-07/msg00904.html

Common conclusion is that it is broken by design (buffer size of the pipe) and it is not a bug ... in fact only irritating cosmetic thing... moving back to man and closing NOTABUG.
Comment 13 Quentin Barnes 2010-06-24 10:19:31 EDT
It's not quite the same problem as in the above three links.  In those cases, the user is quitting out of the pager with 'q' prematurely terminating the pager (the app reading the pipe).  A SIGPIPE should be raised in that case since the reader exited (the pager) while the writer of the pipe was still active.  However, in the case I reported, the problem is now happening during normal operation of the man command.  The reader should not be terminating before the writer has finished writing.
Comment 14 Quentin Barnes 2010-06-24 10:21:41 EDT
Ondrej, I would request the bug be reopened unless I am missing how your three links explains the SIGPIPE behavior in the normal case when the pager is not being prematurely exited.
Comment 15 Ondrej Vasik 2010-06-24 10:32:34 EDT
Ok ... I'm reopening it, but it would be good to know where to reassign the issue. 

It looks like something strange with environment settings for tcsh/ksh ... as starting bash and running ksh again does fix/workaround it. So maybe something with /etc/bashrc - which is not sourced for the case of ksh/tcsh ...

I don't think the issue is in man ... I'll try to check what's wrong with env. settings, so I'm reassigning it to setup, but feel free to reassign it to other suspect if you want.
Comment 16 Quentin Barnes 2010-06-24 11:15:36 EDT
Thanks.  If I recall the old bug from 2005, the error message would come out after q'ing out of the pager.  In the case I reported, the error message comes out immediately before the man page has even rendered.  You can see this with "man wget 2>&1 | less" and the error message will be at the top of the window.

I'm not sure what to do either without tearing more into it.  What's weird is that when I log in with ssh with my ksh session, there's no problem (no error messages from man).  But when I do it when directly logged in either from an xterm or over the serial port, it happens.

It might be though that ssh is altering the default behavior of SIGPIPE (changing its children's inherited sigmask) hiding the underlying problem.  This would probably also explain why ksh/csh is different than bash/sh if their children's sigmasks are different rather than something in the environment.

If it were my bug, I'd try to figure out why the SIGPIPE is being generated in the first place from what is happening in the man command.  I'd figure out which reader/writer pair in the pipeline the reader is dying then make sure that reader is really dying (exiting) prematurely.  Seems that way from the trace log in comment 11.  Then explore why it's dying prematurely.  Maybe comparing the "strace -f ..." output from RHEL5 and RHEL6 may offer a good clue.  It could even be a kernel issue where something changed by default without realizing the change affected user space.
Comment 20 Jan Görig 2010-12-06 07:42:17 EST
Created attachment 464974 [details]
proposed patch

There is a problem in man package that isn't related to commands written in comment 4. Man reads characters from pipe to buffer and then closes it. gzip can expose message about broken pipe if file is bigger than buffer.

Proposed patch attached.
Comment 21 Siddharth Nagar 2011-01-05 15:41:40 EST
We are unable to accommodate a fix for issue in 6.1. Deferring to 6.2.
Comment 22 RHEL Product and Program Management 2011-07-05 19:39:58 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.
Comment 23 Peter Schiffer 2011-11-22 10:31:07 EST
I was able to reproduce this bug on RHEL 6.0 final, but not on RHEL 6.1 and 6.2.

Quentin, please, could you confirm this? If it is working on RHEL >= 6.1 without proposed patch, I'll close this bug as WONTFIX.

Thanks,
peter
Comment 24 Quentin Barnes 2011-11-22 21:55:44 EST
I think you're right.  It stopped reproducing at some point, and I bet it
was when I upgraded from 6u0->6u1.

I'm glad you also checked it with 6u2 to make sure there wasn't a regression.

Seems to be fixed, so please go ahead and close the ticket.

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