Bug#31521: dpkg: dpkg dying in eterm
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.
>> Is there something that support the claim that it is a bug if program A
>> fork/execs program B with SIGPIPE ignored? For example some Unix specs,
>> or a Debian policy doc?
Ian> How about ANSI C ?
What about ANSI C? Is this a fishing expedition?
The standard does not even know about fork. And says nothing
about what programs can expect wrt signal handling in parent
processes.
manoj
--
The first half of our lives is ruined by our parents and the second
half by our children. Clarence Darrow
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: