Bug#317747: [Pkg-shadow-devel] Bug#317747: su -m / suspend / fg broken with zsh

[Alexander Gattin]

On Mon, 11 Jul 2005 03:07:15 -0700 (PDT)
  dean gaudet <dean@arctic.org> wrote:
> both pids 4788 and 4789 have pgrp 4788.  when zsh 
> suspends itself it sends SIGTSTP to -4788.  this TSTP hits
> both zsh(4789) and su(4788) -- which causes zsh(4782)
> to finish its waitpid (it was waiting on su(4788)).

Your analysis is good.

> note that su(4788) has been stopped here *before* it 
> issues raise(SIGSTOP).

You mean it's stopped between waitpid() and raise()?
Will 'su' ever see EINTR after waitpid() (because of 
TSTP)?

> then a while later when you type "fg" in zsh(4782), it 
> sends a CONT to -4788, which wakes both 4788 and 4789...

AFAIU bash sends CONT to 4788. Does zsh really send to 
-4788?

> now unfortunately the su continues on in the new 
> 356_su-stop_cont-proxy patch ...
> it finally gets to do its raise(SIGSTOP)... and presto, that 
> wakes up zsh(4782) again... and now both zsh processes 
> are awake and fighting for the tty.

OK. I saw this behaviour too (one time).
But most of the time I see the next:

penguin% su -m
penguin# suspend

zsh: suspended  su -m
penguin% fg
[1]  + continued  su -m
zsh: suspended (signal)  su -m
penguin% id
uid=1016(xrgttn) gid=1016(xrgttn) 
groups=133(wheel),1016(xrgttn)
penguin% fg
[1]  + continued  su -m
penguin# id
uid=0(root) gid=0(root) groups=0(root)

> i think su should be creating a new process group for 
> its child... 

As I already said, I'd just prefer to block/ignore several 
signals
like TSTP. Most probably I'll do the same as in upstream 
--
block everything (except TERM and ALRM) until exit...