[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

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 :)


|  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: