Bug#841090: Why not just set signal handlers?

2016-11-28 Thread Dmitry Bogatov

[2016-11-28 00:56] Ian Jackson <ijack...@chiark.greenend.org.uk>
>
> part   text/plain1705
> Ian Jackson writes ("Re: Bug#841090: Why not just set signal handlers?"):
> > It's certainly not just my opinion.  This bug was fixed in Python and
> > GHC and xfce4-terminal already.  The bug I filed against lightdm has
> > been fixed.
> >
> >  https://ghc.haskell.org/trac/ghc/ticket/4274
> >  https://twistedmatrix.com/trac/ticket/4199
> >  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733722
>
> Also,
>
> libguestfs
>   https://www.redhat.com/archives/libguestfs/2011-April/msg6.html
>
> launchpad
>   
> https://code.launchpad.net/~jelmer/launchpad/637507-subprocess-sigpipe/+merge/37940
>   Written in Python but the Python fix would have been backwards-
>   incompatible so often applications need patching.  This one is
>   notable because launchpad wants to run dpkg-source -x and motivation
>   in the bug report suggests that dpkg-source -x can break sometimes
>   with SIGPIPE ignored.
>
> pyanaconda
>   
> https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-September/013489.html
>   (another Python one)
>
> chromium
>   
> https://chromium.googlesource.com/native_client/src/native_client/+/master/tools/test_lib.py
>   (another Python one)
>
> ubuntutools
>   https://lists.ubuntu.com/archives/universe-bugs/2011-June/197570.html
>   (another Python one)
>
> dak
>   https://lists.debian.org/debian-dak/2013/10/msg9.html
>   (having this bug in the Python standard library just keeps giving)
>
> I also found this
>
>   http://www.pixelbeat.org/programming/sigpipe_handling.html
>
> I hope that's enough to convince you...

Enough, sure. Will add fix for dvtm.

Thank you.

-- 
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.


pgp5dCkjx4muy.pgp
Description: PGP signature


Bug#841090: Why not just set signal handlers?

2016-11-27 Thread Ian Jackson
Ian Jackson writes ("Re: Bug#841090: Why not just set signal handlers?"):
> It's certainly not just my opinion.  This bug was fixed in Python and
> GHC and xfce4-terminal already.  The bug I filed against lightdm has
> been fixed.
> 
>  https://ghc.haskell.org/trac/ghc/ticket/4274
>  https://twistedmatrix.com/trac/ticket/4199
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733722

Also,

libguestfs
  https://www.redhat.com/archives/libguestfs/2011-April/msg6.html

launchpad
  
https://code.launchpad.net/~jelmer/launchpad/637507-subprocess-sigpipe/+merge/37940
 
  Written in Python but the Python fix would have been backwards-
  incompatible so often applications need patching.  This one is
  notable because launchpad wants to run dpkg-source -x and motivation
  in the bug report suggests that dpkg-source -x can break sometimes
  with SIGPIPE ignored.

pyanaconda
  
https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-September/013489.html
  (another Python one)

chromium
  
https://chromium.googlesource.com/native_client/src/native_client/+/master/tools/test_lib.py
  (another Python one)

ubuntutools
  https://lists.ubuntu.com/archives/universe-bugs/2011-June/197570.html
  (another Python one)

dak
  https://lists.debian.org/debian-dak/2013/10/msg9.html
  (having this bug in the Python standard library just keeps giving)

I also found this

  http://www.pixelbeat.org/programming/sigpipe_handling.html

I hope that's enough to convince you...

Thanks,
Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Bug#841090: Why not just set signal handlers?

2016-11-27 Thread Ian Jackson
Dmitry Bogatov writes ("Re: Bug#841090: Why not just set signal handlers?"):
> [2016-11-26 17:22] Ian Jackson <ijack...@chiark.greenend.org.uk>
> > Any program with sufficiently careful error handling will break when
> > SIGPIPE is ignored.
> 
> If it is careful enough, it can setup all handlers by itself.

Yes, but programs don't (eg, ls, interactive shells, etc., see below)
and are not required to.

> > Interactive shells with SIGPIPE ignored are a latent bug which I want
> > to flush out.
> 
> Can you elaborate?

Just to give an example:

zealot:~> yes | true
zealot:~> echo "${PIPESTATUS[@]}"
141 0
zealot:~> debian_chroot='(nosigpipe)' perl -e '$SIG{PIPE}=IGNORE; exec @ARGV' 
bash
(nosigpipe)zealot:~> yes | true
yes: standard output: Broken pipe
(nosigpipe)zealot:~> echo "${PIPESTATUS[@]}"
1 0
(nosigpipe)zealot:~> 

Observe that in the 2nd case:
 * a spurious message is produced on stderr
 * `yes' calls exit(1) rather than dying due to a fatal SIGPIPE

> > > I just took time to explore dgit and discovered, that it does not work
> > > under dvtm or dtach (did not tested screen or tmux).
> >
> > Please file bugs against those programs.
> 
> I am debian maintainer of dvtm, but I am not convinced yet that removing
> signal(SIGPIPE, SIG_IGN) would do more good then evil. Link to something
> like 'signal(SIGPIPE, SIG_IGN) considered harmful'?

I did look in SUSv3 (POSIX) for something that categorically states
that executing nonconsenting programs with SIGPIPE ignored is
forbidden.  Unfortunately the language in SUSv3 is distressingly
vague.  I would argue that the fact that
  
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03_01
describes SIG_DFL as "Signal-specific default action" means that this
is what an application is allowed to expect from the operating system.
(If as one application, you run another, you obviously need to play
the role of the operating system in that interface.)

> So far, it looks to me that you are artificially pushing your opinion on
> what other programs should or should not do. No offense.

It's certainly not just my opinion.  This bug was fixed in Python and
GHC and xfce4-terminal already.  The bug I filed against lightdm has
been fixed.

 https://ghc.haskell.org/trac/ghc/ticket/4274
 https://twistedmatrix.com/trac/ticket/4199
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733722

Here's a blog post from Colin Watson on the subject:

 http://www.chiark.greenend.org.uk/~cjwatson/blog/python-sigpipe.html

Note that there is nothing wrong with setting SIGPIPE to SIG_IGN,
within your own program, or when executing programs that expect to be
run that way.  It is often very convenient to do so, because in many
(particularly, concurrent) programs SIGPIPE is quite a nuisance.

The bug is in not resetting it after fork and before exec.

> Sure, I was able to find workarounds, but like when things just work,
> don't we?

Well certainly if this kind of thing is going to be common I should
probably make dgit print a warning and reset SIGPIPE itself.

Or maybe I'll write a patch for bash to print the same warning.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Bug#841090: Why not just set signal handlers?

2016-11-27 Thread Dmitry Bogatov

[2016-11-26 17:22] Ian Jackson <ijack...@chiark.greenend.org.uk>
> part   text/plain 920
> Dmitry Bogatov writes ("Bug#841090: Why not just set signal handlers?"):
> > Dear maintainer, can you please explain, why can't dgit just setup
> > signal handlers to value to wanted value instead of aborting?
>
> This is a reasonable question.
>
> Any program with sufficiently careful error handling will break when
> SIGPIPE is ignored.

If it is careful enough, it can setup all handlers by itself.

> Interactive shells with SIGPIPE ignored are a latent bug which I want
> to flush out.

Can you elaborate?

> > I just took time to explore dgit and discovered, that it does not work
> > under dvtm or dtach (did not tested screen or tmux).
>
> Please file bugs against those programs.

I am debian maintainer of dvtm, but I am not convinced yet that removing
signal(SIGPIPE, SIG_IGN) would do more good then evil. Link to something
like 'signal(SIGPIPE, SIG_IGN) considered harmful'?

So far, it looks to me that you are artificially pushing your opinion on
what other programs should or should not do. No offense.

Sure, I was able to find workarounds, but like when things just work,
don't we?

--
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.


pgp87hHuJo8Qe.pgp
Description: PGP signature


Bug#841090: Why not just set signal handlers?

2016-11-26 Thread Ian Jackson
Ian Jackson writes ("Re: Bug#841090: Why not just set signal handlers?"):
> There is a perl one-liner which fixes this in a particuular program,
> which I will make dgit produce in its error message.

I mean it fixe it in  particular shell.

Also please don't think I'm being awkward by not providing it.  I'm
travelling and mjy internet connection is very poor.

There was a lightdm bug #823460 which will contain it somewhere I
think.

I also found a conversation #823754 where I said

   - the easiest way is often to do something like
  re-execing via perl -e '$SIG{PIPE}=""'.)

I hope this is of some use.

Ian.



Bug#841090: Why not just set signal handlers?

2016-11-26 Thread Ian Jackson
Dmitry Bogatov writes ("Bug#841090: Why not just set signal handlers?"):
> Dear maintainer, can you please explain, why can't dgit just setup
> signal handlers to value to wanted value instead of aborting?

This is a reasonable question.

Any program with sufficiently careful error handling will break when
SIGPIPE is ignored.  Interactive shells with SIGPIPE ignored are a
latent bug which I want to flush out.

> I just took time to explore dgit and discovered, that it does not work
> under dvtm or dtach (did not tested screen or tmux).

Please file bugs against those programs.

There is a perl one-liner which fixes this in a particuular program,
which I will make dgit produce in its error message.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Bug#841090: Why not just set signal handlers?

2016-11-25 Thread Dmitry Bogatov

Hello!

Dear maintainer, can you please explain, why can't dgit just setup
signal handlers to value to wanted value instead of aborting?

I just took time to explore dgit and discovered, that it does not work
under dvtm or dtach (did not tested screen or tmux).

-- 
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.


pgp65k_d2OGeE.pgp
Description: PGP signature