[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
server problem
Hello,
I have a small programming question:
I have a server written in C that is supposed to run on linux and on a
sun. It is a normal forking server. Everything works ok but:
On Linux 1.2.13 the forking (fork() call) does not always start a child. I
do not understand why this is so. The Sun behaves itself.
Since every time a connection arrives the server forks, and there is no
child to handle the connection, an unserviced connection (socket) appears in
the netstat output. The socket appears as state TIME_WAIT. The number of
sockets created in this way grows to 24 after which they all close. No
errors occur. I have extensive logging turned on and in the (simplified)
server code:
while(keep_forking)
{
get_connection()
switch(fork())
{
case 0: /* child */
log_this1()
exit
case -1: /* die */
die()
default: /* father */
log_this2();
}
}
log_this2() gets called after every fork() but log_this1() only the first,
the third, fourth ... (n+1)th call. Now this is weird. I have tried various
things and the problem might be in the kernel. httpd running on the same
machine runs ok when from inetd but has the same problem when run
standalone. There are no errors, just a netstat table full of TIME_WAIT
sockets.
I would appreciate any help or ideas,
TIA, Peter (plp@actcom.co.il)
Here I append an extempt from the log:
NOTES:
- I have deleted some lines.
- cpid: is the number of a child that was not 'born'. cpid is logged in the
fork do-while loop. If the child is 'born' then cpid also appears as CHILD
pid - fork seems to have a problem returning (int)0 ?!
- Software versions:
kernel: 1.2.13 plain (recompiled 4drivers etc)
libc.so.5 -> libc.so.5.0.9 (May 19 1995), from Slackware
- the server is linked against libc.so.5
- the logs continue in the same spirit until the local socket == 23 after
which the first fork succeeds, and gives local = 23. Then the stuff goes on
as before, with local numbers growing towards 56...
- I have the full kernel source and the full libc source installed and I
have traced the fork call. I can't see anything wrong there but I'm just
a programmer :) (and in my spare time at that).
- Dead children and other signals are taken care of. No processes remain in
the process table when this happens.
-- snip --
+++ SERVER START: Sat Jul 12 23:08:27 1997
logsocks: From: 127.0.0.1 Socket: 22533 Local: 3
++ CHILD: 2151 Sat Jul 12 23:08:41 1997
verbose: CHILD:
UID: 502 EUID: 502
GID: 0 EGID: 0
PID: 2151 PPID: 2149
request: /server.txt
-- CHILD: 2151 Sat Jul 12 23:08:41 1997
logsocks: From: 127.0.0.1 Socket: 22533 Local: 3
cpid: 2151
logsocks: From: 127.0.0.1 Socket: 22789 Local: 4
++ CHILD: 2152 Sat Jul 12 23:08:42 1997
verbose: CHILD:
UID: 502 EUID: 502
GID: 0 EGID: 0
PID: 2152 PPID: 2149
request: /server.txt
-- CHILD: 2152 Sat Jul 12 23:08:42 1997
logsocks: From: 127.0.0.1 Socket: 22533 Local: 3
cpid: 2151
logsocks: From: 127.0.0.1 Socket: 22789 Local: 4
cpid: 2152
logsocks: From: 127.0.0.1 Socket: 23045 Local: 5
++ CHILD: 2153 Sat Jul 12 23:08:50 1997
verbose: CHILD:
UID: 502 EUID: 502
GID: 0 EGID: 0
PID: 2153 PPID: 2149
request: /server.txt
-- CHILD: 2153 Sat Jul 12 23:08:50 1997
logsocks: From: 127.0.0.1 Socket: 22533 Local: 3
cpid: 2151
logsocks: From: 127.0.0.1 Socket: 22789 Local: 4
cpid: 2152
logsocks: From: 127.0.0.1 Socket: 23045 Local: 5
cpid: 2153
logsocks: From: 127.0.0.1 Socket: 23301 Local: 6
++ CHILD: 11257 Sun Jul 13 00:39:01 1997
verbose: CHILD:
UID: 502 EUID: 502
GID: 0 EGID: 0
PID: 11257 PPID: 2149
request: /server.txt
-- CHILD: 11257 Sun Jul 13 00:39:01 1997
logsocks: From: 127.0.0.1 Socket: 22533 Local: 3
cpid: 2151
logsocks: From: 127.0.0.1 Socket: 22789 Local: 4
cpid: 2152
logsocks: From: 127.0.0.1 Socket: 23045 Local: 5
cpid: 2153
logsocks: From: 127.0.0.1 Socket: 23301 Local: 6
cpid: 11257
logsocks: From: 127.0.0.1 Socket: 23557 Local: 7
++ CHILD: 11258 Sun Jul 13 00:39:02 1997
verbose: CHILD:
UID: 502 EUID: 502
GID: 0 EGID: 0
PID: 11258 PPID: 2149
request: /server.txt
-- CHILD: 11258 Sun Jul 13 00:39:02 1997
--snip--
Follow-Ups: