read on socket shows EOF... but only when app is running in background

[Ruud Schramp]

Hello All,

Does anybody know other reasons a TCP Socket will read eof besides being
closed localy or receiving a FIN packet?

My multi threaded server application doesn't work when run in the
background. The application is intended to run as a daemon so I want to
create a commandline option that puts it in the background. It does work
when run in the foreground, even when started with a "&" option, but not
when an internal fork is used.

I did this (in lots of other programs as well) by putting a fork() function
almost at startup in which the parent exits and the child continues running.

This forking itself works, so the application runs in the background, but
now when I connect to it with TCP (the app has a server socket) the client
socket is immediately "closed" again (saying it will unblock for read,
reading the EOF (read returns 0)). The client connecting has not terminated
the TCP connection, also tcpdump doesn't show a FIN packet being sent to the
server. After verification with strace I see that no signals generated
within the timeframe of these events. Also no unexpeced closes are created
by the server application.

comparison of the strace logging of the application run in the foreground
with the strace logging when forked show no difference upto the reception of
the EOF.

Unfortunately the application is too big to show in the mailing list. I am
afraid that I will not be able to reproduce the problem on a micro scale
because, well I can't isolate the event. To my best knowledge it should
work....

Anyone seen this type of events before?

regards,

Ruud Schramp

[p***@icke-reklam.ipsec.nu]

Post by Ruud Schramp
Hello All,
Does anybody know other reasons a TCP Socket will read eof besides being
closed localy or receiving a FIN packet?

Yes.

The stack might not have all the requested number of bytes available,
giving your read(2) only the amount it has ( the rest is in
transit and will be avalable later)

Always test the number returned from read(), never assume
the chunks written is equals the chunks read.


See p9 and 77 in UNIX network programming volume 1 by R stevens,
isbn 0-13-490012-x

[Nils R. Weller]

Post by p***@icke-reklam.ipsec.nu

Post by Ruud Schramp
Hello All,
Does anybody know other reasons a TCP Socket will read eof besides being
closed localy or receiving a FIN packet?

Yes.
The stack might not have all the requested number of bytes available,
giving your read(2) only the amount it has ( the rest is in
transit and will be avalable later)

However, this will never result in read() returning zero. The only case
where the byte-stream like behavior can lead to an apparently premature
EOF is where you perform a few read() calls and got more data than you
expected. But this is very unlikely to be the problem because it would
require the OP to discard the read() return value and to assume the
receipt of an amount of bytes that does not match the buffer size he
passed to read().

[Nils Weller]

Post by Ruud Schramp
Does anybody know other reasons a TCP Socket will read eof besides being
closed localy or receiving a FIN packet?

No.

Post by Ruud Schramp
My multi threaded server application doesn't work when run in the
background.

The fact that you call fork() in a multithreaded application may be your
first problem already. Do you create your threads before calling fork()
or afterwards, and does the parent process perform any other actions
related to multithreading before it exits (such as acquiring mutexes)?

Post by Ruud Schramp
The application is intended to run as a daemon so I want to create a
commandline option that puts it in the background. It does work when
run in the foreground, even when started with a "&" option, but not
when an internal fork is used.

I recommend that you call the setsid() function after performing the
fork(). Also, the parent should exit by calling _exit(), not exit() (a
return from main() will call exit().)

But from the information you have supplied, it's hard to guess what's
wrong. This certainly does not seem like a common programming problem
to me, or at least it's not one I have experienced myself. What else
have you tried on the server side? Is the server structured in such a
way that you can constantly monitor the socket for its validity?