Bug#31521: dpkg: dpkg dying in eterm
On 1 Mar 1999, Manoj Srivastava wrote:
> Hi,
> >>"Ian" == Ian Jackson <ian@chiark.greenend.org.uk> writes:
>
> Ian> Klaus Weide writes ("Bug#31521: dpkg: dpkg dying in eterm"):
> >> Ian Jackson wrote:
> >> > I know what is causing dpkg to misbehave and it's this
> >> > SIGPIPE problem. That's not dpkg's fault.
> >>
> >> Pardon me, but it seems to me that if dpkg needs SIGPIPE non-ignored
> >> to function properly, then it is up to dpkg to make it so. Which
> >> should be very simple to do. Or is there ever a reason to honor a
> >> parent process's SIG_IGN for SIGPIPE?
>
> Ian> There might be. The main point is that a program is entitled to
> Ian> assume that all signal handlers start in the default state.
>
> Really? Where do we get that from? The tenets of defensive
> programming seem to dictate that is your code crashes and burns
> depending on some state of a signal handler, you should take care of
> it.
So every single program should start with a long set of
signal(___,SIG_DFL)?
And reset all environment variables to some useful default?
...
The way I see this, is that the parent process *may* have reset the
signals for some bona fide reason (debuggers play this kind of trickery, I
believe).
However, the gnome-* packages have *no* valid reason to reset SIGPIPE for
child processes. So it's a bug if they do.
If I destroy PATH and IFS, I can expect subprocesses to break. I don't
file bugs against them for not checking.. (unless they're suid root, of
course :)
Jules
/----------------+-------------------------------+---------------------\
| Jelibean aka | jules@jellybean.co.uk | 6 Evelyn Rd |
| Jules aka | jules@debian.org | Richmond, Surrey |
| Julian Bean | jmlb2@hermes.cam.ac.uk | TW9 2TF *UK* |
+----------------+-------------------------------+---------------------+
| War doesn't demonstrate who's right... just who's left. |
| When privacy is outlawed... only the outlaws have privacy. |
\----------------------------------------------------------------------/
Reply to: