Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

socket connection to nowhere?!

0 views
Skip to first unread message

mark.b...@thales-is.com

unread,
Sep 8, 2008, 6:51:35 AM9/8/08
to
I have 3 Linux bones, 1 server and 2 clients - one client active at
any one time, as software dies on one client, watchdog software starts
the other client.
At the server, there are actually 2 relevant processes running, the
client opens a socket connection to each.

As client1 software is stopped, both server processes notice the
disconnection.
client2 then starts up, and issues connection request to each server
process in turn.
The first server process notices the incoming connection, accepts it
and all is fine.
The second server process never notices the incoming connection -
however client2 thinks that both connections are OK!!
Looking in netstat on client2 shows both connections ESTABLISHED;
looking in netstat -p at the server shows the connections ESTABLISHED,
but the second connection has no process listed (just a dash).

Any ideas what might be happening, or best way to investigate?
TIA
M

Johannes Bauer

unread,
Sep 8, 2008, 7:03:26 AM9/8/08
to
mark.b...@thales-is.com schrieb:

> Looking in netstat on client2 shows both connections ESTABLISHED;
> looking in netstat -p at the server shows the connections ESTABLISHED,
> but the second connection has no process listed (just a dash).
>
> Any ideas what might be happening, or best way to investigate?

Could it be that your client process just dies instantaniously after
establishing the connection (SIGSEGV comes to mind) and the connection
is still "hanging" in the kernel before timing out? This should happen
IIRC after 12 minutes - but I might be horribly mistaken here and
confusing it with something else.

Regards,
Johannes

mark.b...@thales-is.com

unread,
Sep 8, 2008, 7:18:58 AM9/8/08
to
On 8 Sep, 12:03, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:

> I wrote:
>
> > Looking in netstat on client2 shows both connections ESTABLISHED;
> > looking in netstat -p at the server shows the connections ESTABLISHED,
> > but the second connection has no process listed (just a dash).
>
> Could it be that your client process just dies instantaniously after
> establishing the connection (SIGSEGV comes to mind) and the connection
> is still "hanging" in the kernel before timing out?

No processes are dying.
Client thinks it has successfully connected to 2 processes.
Process 1 on server receives incoming connection request.
Process 2 on server does not receive request.
It looks like something else on the server is picking up the
connection

M

mark.b...@thales-is.com

unread,
Sep 8, 2008, 7:20:37 AM9/8/08
to
On 8 Sep, 11:51, I wrote:
> The second server process never notices the incoming connection -
> however client2 thinks that both connections are OK!!
> Looking in netstat on client2 shows both connections ESTABLISHED;
> looking in netstat -p at the server shows the connections ESTABLISHED,
> but the second connection has no process listed (just a dash).

I should say that this is only intermittent.
Sometimes it works OK, i.e. Process 2 at the server notices the
connection request, and netstat shows all connections correct

M

Johannes Bauer

unread,
Sep 8, 2008, 7:52:42 AM9/8/08
to
mark.b...@thales-is.com schrieb:

> No processes are dying.
> Client thinks it has successfully connected to 2 processes.
> Process 1 on server receives incoming connection request.
> Process 2 on server does not receive request.
> It looks like something else on the server is picking up the
> connection

Have you done proper error checking? Do the socket() and connect() calls
of the client *really* succeeed? Do the socket(), bind(), listen(),
accept() calls of the server *really* succeed? If bind() succeeds in
process 2, then it should be impossible any other process picks up the
connection (because only one server can bind to a address/port tuple at
a time).

Regards,
Johannes

Rainer Weikusat

unread,
Sep 8, 2008, 8:10:30 AM9/8/08
to

There are two causes (I know of) for the dash:

- user executing netstat -p doesn't have the necessary
privileges to determine this information for a particular
socket

- the kernel has completed the three-way-handshake to
establish a new connection, but the procces supposed to
'serve' the socket hasn't yet accepted it

The latter has been determined by running the program quoted below
(and netcat to actually connect to the socket). Could it be that your
server stops calling accept for some (to be determined) reason for an
'extended' period of time?

Connection test program:

#include <netinet/in.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/socket.h>
#include <unistd.h>

void dummy(int unused)
{
(void)unused;
}

int main(void)
{
struct sockaddr_in sin;
int fd, rc;

sin.sin_family = AF_INET;
sin.sin_port = htons(4711);
sin.sin_addr.s_addr = INADDR_ANY;

fd = socket(PF_INET, SOCK_STREAM, 0);
if (fd == -1) {
perror("socket");
exit(1);
}

rc = bind(fd, (struct sockaddr *)&sin, sizeof(sin));
if (rc == -1) {
perror("bind");
exit(1);
}

rc = listen(fd, 5);
if (rc == -1) {
perror("listen");
exit(1);
}

signal(SIGUSR1, dummy);

pause();

rc = accept(fd, NULL, NULL);
if (rc == -1) {
perror("accept");
exit(1);
}

pause();
return 0;
}

0 new messages