We wrote an application that listens on a particular port and serves up
data to clients as needed. When the application starts, it listens on
all interfaces/IP's on port 9998, showing up as '*.9998 LISTEN' when
looking at it with netstat.
However, we want to move the application to port 80, since it is a web
based application, however we already have apache running on port 80. So,
we will be assigning another IP address to the machine so that apache
runs on one IP of port 80 (actually, it already runs that way), and this
web application will run on the other IP address on port 80. Nothing
magical going on here.
When modifying the code to listen on a single IP address, it seems to
fail. Further investigation seems to point to the IO libraries (such
as printf(), read() and write() functions) as the culprit. If any of
the IO functions are called, binding to a single IP address fails. If
they aren't called, binding to a single IP address works.
I have attached a C program that demonstrates the problem.
Actually, we just played with it some more and found out that if the
test program does not call setsockopt(), we can get the binding to work
if a print statement before it has more than 7 characters in it. If
you have less than that, it fails. So, printing "Hello" fails, but
printing "Hello World" works. Strange, eh? Okay, adding back in the
setsockopt() function call causes any print statements before binding
to fail.
All I can say is that this is totally bizarre. I don't know why Apache
seems to work... I have a feeling that it has something to do with the
fact that Apache disconnects itself from the controlling terminal before
it does anything else. I haven't added code to the test program yet to
see if this makes any difference. We tried nohupping the test program
and it made no difference at all... but that is probably because nohup
really doesn't kick in until you log out and the controlling terminal
ceases to exist... so...
There must be some weird interaction going on with the libraries. The
test program works absolutely fine on Linux and Solaris. I have tried
the test program on Tru64 v5.1 and v5.1a, same problem. I have also
tried the test program within and outside of our TruCluster environment
and that doesn't seem to change things as well... so...
If anyone has any insight, it would be greatly appreciated. We will
probably be placing a call to Compaq support shortly, but I thought I
would drop a line here first.
Please CC any responses to me on this issue to my coworker as well. I
have included her in the CC list above.
Thanks,
Scott
--
+-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-+
Scott W. Adkins http://www.cns.ohiou.edu/~sadkins/
UNIX Systems Engineer mailto:adkinss_at_ohio.edu
ICQ 7626282 Work (740)593-9478 Fax (740)593-1944
+-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-+
PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/
Received on Wed Mar 06 2002 - 16:36:45 NZDT