Red Hat Bugzilla – Bug 75341
gnome-terminal starts subprocess with SIGPIPE set to ignore
Last modified: 2007-04-18 12:47:17 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020809
Description of problem:
gnome-terminal is starting subprocesses with SIGPIPE set to ignore. This causes
problems with shells such as tcsh that don't reset SIGPIPE to the default action
upon starting (on the contrary bash does reset it).
This shows very clearly with the man command that complains under tcsh running
in a gnome-terminal, which complains loudly.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. set SHELL env. var. to /bin/tcsh (e.g., setenv SHELL /bin/tcsh)
2. run "gnome-terminal --disable-factory" (to start with above SHELL)
3. run "man man"
Actual Results: man complains with messages:
gunzip: stdout: Broken pipe
grotty:<standard input>:4182:fatal error: output error
Expected Results: No complains and piped commands work as expected.
Inspecting the SigIgn field of /proc/<pid>/status for the gnome-terminal
process, tcsh and any process started from the tcsh shell it shows that SIGPIPE
is incorrectly set to ignore.
The symptom of this bug is reported as man bug #75213
I did some more research and it is liblinc and gnome-vfs2 that are setting
SIGPIPE to ignore upon initialization (by calling signal(SIGPIPE,SIG_IGN)).
For linc it is done in linc_init() (linc-0.5.2-2)
For gnome-vfs2 it is done in gnome_vfs_init() and gnome_vfs_postinit()
The problem is that vte does not reenable SIGPIPE in the forked process before
the exec. I tried just reenabling it in vte and it works fine, although it might
not be the best solution (patch next).
Created attachment 79324 [details]
Fix to reenable SIGPIPE in child process just before exec'ing command
Thanks! Fixing for 0.9.2 and later.
*** Bug 75213 has been marked as a duplicate of this bug. ***