I was debugging a third party program using truss on Solaris 2.8

I saw that a particular server socket was continuously returning on
poll() but when it does an accept(), it comes back with EAGAIN.
Looking at EAGAIN, I saw that, this happens when there is no pending
connect requests, but when the socket does an accept() on non-blocking
mode.

I also did a tcpdump and found no incoming packets for this particular
port

Any ideas what might be going on
Thanks
--sony

[ Post a follow-up to this message ]

sonyantony@hotmail.com (Sony Antony) writes:

> I was debugging a third party program using truss on Solaris 2.8
>
> I saw that a particular server socket was continuously returning on
> poll() but when it does an accept(), it comes back with EAGAIN.
> Looking at EAGAIN, I saw that, this happens when there is no pending
> connect requests, but when the socket does an accept() on non-blocking
> mode.
>
> I also did a tcpdump and found no incoming packets for this particular
> port
>
> Any ideas what might be going on

Trace all the system calls related to that socket and write a program
to do the same operations.  Maybe it will reveal something.

--
Måns Rullgård
mru@mru.ath.cx

[ Post a follow-up to this message ]

On Wed, 25 Aug 2004 23:20:59 -0700, Sony Antony wrote:

> I saw that a particular server socket was continuously returning on
> poll() but when it does an accept(), it comes back with EAGAIN.
> Looking at EAGAIN, I saw that, this happens when there is no pending
> connect requests, but when the socket does an accept() on non-blocking
> mode.

A possibility could be that the third party program does not
react correctly to the the poll() revents.

--
mail1dotstofanetdotdk

[ Post a follow-up to this message ]

"Bjorn Reese" <breese@see.signature> wrote in message news:<pan.2004.08.26.13.14.24.515471@s
ee.signature>...
> On Wed, 25 Aug 2004 23:20:59 -0700, Sony Antony wrote:
> 
>
> A possibility could be that the third party program does not
> react correctly to the the poll() revents.


I could not find anything strange with the way application was
reacting. Is it possible that this is a SYN attack or something. But
then I didnt see anything coming in for this port when I used tcpdump.
Pl note the poll() returning POLLRDNORM, but then returning EAGAIN on
accept(). Since the application is doing this in a tight loop, it ends
up taking up all of teh cpu and the file system gets filled up in
about an hour with the error messages. Any clues will be appreciated.


--sony

poll(0xFCD018F8, 9, 86400000)                   = 1
fd=11 ev=POLLRDNORM|POLLRDBAND rev=0
fd=15 ev=POLLRDNORM|POLLRDBAND rev=0
fd=17 ev=POLLRDNORM|POLLRDBAND rev=POLLRDNORM
fd=18 ev=POLLRDNORM|POLLRDBAND rev=0
fd=20 ev=POLLRDNORM|POLLRDBAND rev=0
fd=29 ev=POLLRDNORM|POLLRDBAND rev=0
fd=30 ev=POLLRDNORM|POLLRDBAND rev=0
fd=31 ev=POLLRDNORM|POLLRDBAND rev=0
fd=32 ev=POLLRDNORM|POLLRDBAND rev=0
accept(17, 0xFCD01970, 0xFCD0198C, 1)           Err#11 EAGAIN
open("/opt/app/iona/logs/orbix2000/logs/locator.log.25082004",
O_WRONLY|O_APPEND|O_CREAT, 0666) = 33
write(2, " E R R O R :  ", 7)                   = 7
lseek(2, 0, SEEK_CUR)                           = 0x2C56465B
lseek(2, 0, SEEK_CUR)                           = 0x2C56465B
lseek(1, 0, SEEK_CUR)                           = 14947
lseek(2, 0, SEEK_CUR)                           = 0x2C56465B
write(2, 0x0003EA10, 67)                        = 67
e r r o r   a c c e p t i n g   c o n n e c t i o n   o n   E r
r o r   0   [ e r r n o :   0 ] .   [ 0 . 0 . 0 . 0   :   3 2 7
8 5 ]

[ Post a follow-up to this message ]