|
Home > Archive > Unix Programming > August 2004 > EAGAIN mystery
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Sony Antony 2004-08-27, 6:21 pm |
| 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
| |
| Måns Rullgård 2004-08-27, 6:21 pm |
| 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
| |
| Bjorn Reese 2004-08-27, 6:21 pm |
| 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
| |
| Sony Antony 2004-08-27, 6:21 pm |
| "Bjorn Reese" <breese@see.signature> wrote in message news:<pan.2004.08.26.13.14.24.515471@see.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 ]
|
|
|
|
|