On Mon, 11 Jul 2005 03:07:15 -0700 (PDT)
dean gaudet <[EMAIL PROTECTED]> 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...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
