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): gnome-terminal-2.0.1-5 How reproducible: Always 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. Additional info: 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() (gnome-vfs2-2.0.2-5). 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. ***