Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
send() failing, why? netstat not showing high queue
25 views
Skip to first unread message
mark.b...@thales-is.com
Jun 11, 2012, 7:44:16 AM6/11/12
to
Hello,
I have two programs for which I have source (but cannot easily change). Process A sends lots of messages to process B via TCP socket, busier at some times than others.
System has been operating OK for years (with restarts as needed every few weeks/months); but for the last few days I see frequent error messages, which appear to be caused by send() failing, but unfortunately the code does not log why (perror() etc). As the programs are very busy & an important system I am loath to attach a debugger and print errno.
I thought maybe too much data has been sent, and the TCP buffers are full, but when I run netstat, I don't see any build-up in SendQ or RecvQ columns. Should I?
The next thing you need to know is that process A is multi-threaded, and each thread sends messages to process B. In netstat, I see two of the threads have a fixed number in SendQ (something like 56 for one and 42 for the other). Does this mean that B is not reading their sockets at all? But still, why would send() fail?
Any ideas?
TIA
Mark
I have two programs for which I have source (but cannot easily change). Process A sends lots of messages to process B via TCP socket, busier at some times than others.
System has been operating OK for years (with restarts as needed every few weeks/months); but for the last few days I see frequent error messages, which appear to be caused by send() failing, but unfortunately the code does not log why (perror() etc). As the programs are very busy & an important system I am loath to attach a debugger and print errno.
I thought maybe too much data has been sent, and the TCP buffers are full, but when I run netstat, I don't see any build-up in SendQ or RecvQ columns. Should I?
The next thing you need to know is that process A is multi-threaded, and each thread sends messages to process B. In netstat, I see two of the threads have a fixed number in SendQ (something like 56 for one and 42 for the other). Does this mean that B is not reading their sockets at all? But still, why would send() fail?
Any ideas?
TIA
Mark
Richard Kettlewell
Jun 11, 2012, 8:19:53 AM6/11/12
to
mark.b...@thales-is.com writes:
> System has been operating OK for years (with restarts as needed every
> few weeks/months); but for the last few days I see frequent error
> messages, which appear to be caused by send() failing, but
> unfortunately the code does not log why (perror() etc). As the
> programs are very busy & an important system I am loath to attach a
> debugger and print errno.
strace (or truss etc depending on platform) should reveal the error code
> System has been operating OK for years (with restarts as needed every
> few weeks/months); but for the last few days I see frequent error
> messages, which appear to be caused by send() failing, but
> unfortunately the code does not log why (perror() etc). As the
> programs are very busy & an important system I am loath to attach a
> debugger and print errno.
in a less intrusive way.
--
http://www.greenend.org.uk/rjk/
Adam Wysocki
Jun 11, 2012, 10:39:18 AM6/11/12
to
mark.b...@thales-is.com wrote:
> I see frequent error messages, which appear to be caused by send()
> failing, but unfortunately the code does not log why (perror() etc).
> As the programs are very busy & an important system I am loath to
> attach a debugger and print errno.
Maybe strace will do? It's still a debugger of some kind (because it uses
> I see frequent error messages, which appear to be caused by send()
> failing, but unfortunately the code does not log why (perror() etc).
> As the programs are very busy & an important system I am loath to
> attach a debugger and print errno.
ptrace to attach to a process), but proper code will not crash from using
it (and if it does, you can just simply restart it).
Maybe send() is interrupted by a signal?
--
Gof
0 new messages