Date: Wed, 25 Dec 2002 13:41:02 -0800 From: Peter Wemm <peter@wemm.org> To: Dmitry Morozovsky <marck@rinet.ru> Cc: Gordon Tetlow <gordont@gnf.org>, "Michael C . Wu" <keichii@FreeBSD.ORG>, "" <cvs-committers@FreeBSD.ORG>, "" <cvs-all@FreeBSD.ORG> Subject: Re: cvs commit: CVSROOT modules Message-ID: <20021225214102.CABDB2A8A5@canning.wemm.org> In-Reply-To: <20021225150303.F88569@woozle.rinet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Dmitry Morozovsky wrote:
> On Wed, 25 Dec 2002, Peter Wemm wrote:
>
> PW> > PW> > > PR: 41701d by signal 2.
> PW> > PW> > ^^^^^^^^^^^^^^
> PW> > PW> > Anyone know how that snuck in there?
> PW> > PW>
> PW> > PW> Good question. I suspect a cut/paste glitch, because signal 2 is:
> PW> > PW> #define SIGINT 2 /* interrupt */
> PW> > PW>
> PW> > PW> You cant send SIGINT to the cvs server on repoman.. it only can ge
t a
> PW> > PW> SIGPIPE.
> PW> >
> PW> > I think it's tail of 'Terminated by signal 2' by ssh ;-)
> PW>
> PW> Sure, but I'm not sure how the SIGINT is propagating across the pipe in
> PW> non-tty mode. There should be no job control or tty signals involved at
> PW> all on the repo server.. Note "should" - I haven't actually read the
> PW> code.. sshd could be doing something I'm not expecting.
>
> Hmm, that seems to be exactly the case in absence of tty job control:
>
> marck@woozle:~> ssh hostname cat
> ^CKilled by signal 2.
>
> So, is it possibly a result of a command like 'ssh repoman cvs commit' ?
Nope. It is the client side ssh that prints this message:
peter@overcee[1:29pm]~-101> ssh localhost cat
^CKilled by signal 2.
Here are the kdumps for each of the components. There is a client side
"ssh" and a server side "sshd", "tcsh -c cat" and "cat". A trace for each
is attached.
peter@overcee[1:32pm]~-104# kdump -f /tmp/ssh.kt
29013 ssh RET select -1 errno 4 Interrupted system call
29013 ssh PSIG SIGINT caught handler=0x80514f0 mask=0x0 code=0x0
29013 ssh CALL sigreturn(0xbfbfef70)
29013 ssh RET sigreturn JUSTRETURN
29013 ssh CALL ioctl(0,TIOCGETA,0xbfbff2f0)
29013 ssh RET ioctl 0
29013 ssh CALL ioctl(0x1,TIOCGETA,0xbfbff2f0)
29013 ssh RET ioctl 0
29013 ssh CALL ioctl(0x2,TIOCGETA,0xbfbff2f0)
29013 ssh RET ioctl 0
29013 ssh CALL write(0x2,0xbfbfe120,0x15)
29013 ssh GIO fd 2 wrote 21 bytes
"Killed by signal 2.\r
"
29013 ssh RET write 21/0x15
29013 ssh CALL shutdown(0x3,0x2)
29013 ssh RET shutdown 0
29013 ssh CALL close(0x3)
29013 ssh RET close 0
29013 ssh CALL exit(0xff)
Note: ssh (not sshd) takes the signal and closes the socket and prints
the message. On the server side:
peter@overcee[1:31pm]~-101> kdump -f /tmp/cat.kt
29019 cat RET read 0
29019 cat CALL close(0x1)
29019 cat RET close 0
29019 cat CALL exit(0)
ie: cat didn't get the SIGINT.
peter@overcee[1:31pm]~-101> kdump -f /tmp/tcsh.kt
29015 tcsh RET sigsuspend -1 errno 4 Interrupted system call
29015 tcsh PSIG SIGCHLD caught handler=0x80611f0 mask=0x80002 code=0x0
29015 tcsh CALL wait4(0xffffffff,0xbfbfb46c,0x1,0xbfbfb470)
29015 tcsh RET wait4 29019/0x715b
29015 tcsh CALL wait4(0xffffffff,0xbfbfb46c,0x1,0xbfbfb470)
29015 tcsh RET wait4 -1 errno 10 No child processes
29015 tcsh CALL sigreturn(0xbfbfb500)
29015 tcsh RET sigreturn JUSTRETURN
29015 tcsh CALL sigprocmask(0x3,0xbfbfb820,0xbfbfb810)
29015 tcsh RET sigprocmask 0
29015 tcsh CALL sigprocmask(0x1,0,0x815159c)
29015 tcsh RET sigprocmask 0
29015 tcsh CALL sigprocmask(0x1,0xbfbfda70,0xbfbfda60)
29015 tcsh RET sigprocmask 0
29015 tcsh CALL sigprocmask(0x3,0xbfbfda70,0xbfbfda60)
29015 tcsh RET sigprocmask 0
29015 tcsh CALL exit(0)
Neither did the shell.. (tcsh -c 'cat')
And last but not least, the server side sshd...
peter@overcee[1:31pm]/home/peter-102# kdump -f /tmp/sshd.kt
29014 sshd RET select 1
29014 sshd CALL read(0x4,0xbfbfb3e0,0x4000)
29014 sshd GIO fd 4 read 0 bytes
""
29014 sshd RET read 0
29014 sshd CALL sigprocmask(0x1,0x28081700,0xbfbfb270)
29014 sshd RET sigprocmask 0
29014 sshd CALL sigprocmask(0x3,0x28081710,0)
29014 sshd RET sigprocmask 0
29014 sshd CALL sigprocmask(0x1,0x28081700,0xbfbfb270)
29014 sshd RET sigprocmask 0
29014 sshd CALL munmap(0x282b0000,0x2000)
29014 sshd RET munmap 0
29014 sshd CALL sigprocmask(0x3,0x28081710,0)
29014 sshd RET sigprocmask 0
29014 sshd CALL sigprocmask(0x1,0x28081700,0xbfbfb290)
29014 sshd RET sigprocmask 0
29014 sshd CALL sigprocmask(0x3,0x28081710,0)
29014 sshd RET sigprocmask 0
29014 sshd CALL sigprocmask(0x1,0x28081700,0xbfbfb290)
29014 sshd RET sigprocmask 0
29014 sshd CALL munmap(0x282ae000,0x2000)
29014 sshd RET munmap 0
29014 sshd CALL sigprocmask(0x3,0x28081710,0)
29014 sshd RET sigprocmask 0
29014 sshd CALL sigprocmask(0x1,0x28081700,0xbfbfb2b0)
29014 sshd RET sigprocmask 0
29014 sshd CALL sigprocmask(0x3,0x28081710,0)
29014 sshd RET sigprocmask 0
29014 sshd CALL sigprocmask(0x1,0x28081700,0xbfbfb2b0)
29014 sshd RET sigprocmask 0
29014 sshd CALL munmap(0x282ac000,0x2000)
29014 sshd RET munmap 0
29014 sshd CALL sigprocmask(0x3,0x28081710,0)
29014 sshd RET sigprocmask 0
29014 sshd CALL sigprocmask(0x1,0x28081700,0xbfbfb290)
29014 sshd RET sigprocmask 0
29014 sshd CALL sigprocmask(0x3,0x28081710,0)
29014 sshd RET sigprocmask 0
29014 sshd CALL sigprocmask(0x1,0x28081700,0xbfbfb290)
29014 sshd RET sigprocmask 0
29014 sshd CALL munmap(0x282b2000,0x4000)
29014 sshd RET munmap 0
29014 sshd CALL munmap(0x282b6000,0x5000)
29014 sshd RET munmap 0
29014 sshd CALL munmap(0x282bb000,0x9000)
29014 sshd RET munmap 0
29014 sshd CALL sigprocmask(0x3,0x28081710,0)
29014 sshd RET sigprocmask 0
29014 sshd CALL sigprocmask(0x1,0x28081700,0xbfbfb2b0)
29014 sshd RET sigprocmask 0
29014 sshd CALL sigprocmask(0x3,0x28081710,0)
29014 sshd RET sigprocmask 0
29014 sshd CALL sigprocmask(0x1,0x28081700,0xbfbfb2b0)
29014 sshd RET sigprocmask 0
29014 sshd CALL munmap(0x282c4000,0x3000)
29014 sshd RET munmap 0
29014 sshd CALL sigprocmask(0x3,0x28081710,0)
29014 sshd RET sigprocmask 0
29014 sshd CALL sigprocmask(0x1,0x28081700,0xbfbfb2b0)
29014 sshd RET sigprocmask 0
29014 sshd RET sigprocmask 0
29014 sshd CALL sigprocmask(0x1,0x28081700,0xbfbfb2b0)
29014 sshd RET sigprocmask 0
29014 sshd CALL munmap(0x282c7000,0x2000)
29014 sshd RET munmap 0
29014 sshd CALL sigprocmask(0x3,0x28081710,0)
29014 sshd RET sigprocmask 0
29014 sshd CALL sigprocmask(0x1,0x28081700,0xbfbfb2b0)
29014 sshd RET sigprocmask 0
29014 sshd CALL sigprocmask(0x3,0x28081710,0)
29014 sshd RET sigprocmask 0
29014 sshd CALL sigprocmask(0x1,0x28081700,0xbfbfb2b0)
29014 sshd RET sigprocmask 0
29014 sshd CALL munmap(0x282c9000,0x2000)
29014 sshd RET munmap 0
29014 sshd CALL sigprocmask(0x3,0x28081710,0)
29014 sshd RET sigprocmask 0
29014 sshd CALL shutdown(0x4,0x2)
29014 sshd RET shutdown 0
29014 sshd CALL close(0x4)
29014 sshd RET close 0
29014 sshd CALL exit(0xff)
No signals there either. This 'Killed by signal 2' message is purely
client side. No writes either.. It returns 'closed' from the read and then
dives into the cleanup.
I stand by my speculation that it was a cut/paste glitch. I thought for a
moment that it might have been a result of me upgrading the repository
server and that it might have hit the 'shutdown -r now' which does a
killall.. the times were very close but it was one day out..
BTW; is sigprocmask(2) truely mpsafe? This is a heavily used syscall..
Cheers,
-Peter
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021225214102.CABDB2A8A5>