Re: xinetd still buggy?

[ABrady <kcsmart kc rr com>]

On Thu, 10 May 2001 14:09:17 -0400 "Eric Wood" <eric interplas com> spake
unto us:

If there was a discussion about this, I missed it. But, I thought I was
having a weird problem (I was) and just didn't have enough time to
experiment with it (I didn't) and planned on researching it and asking if
I couldn't locate an answer (I woulda). This, however, took care of it.

I was waiting up 45 seconds for 'localhost' to respond and pass my mail. I
was waiting that long or longer for a page to _BEGIN_ loading while
running through junkbuster->squid->internet. Mind you, I'm using cable and
until xinetd started giving me fits I always had everything almost
instantly. None of this was happening until awhile back (the closest I can
get is 7.0 or wolverine or even 7.1). I installed the file and everything
works as it should!

> Here's a walkthrough of why xinetd still suffers from the wait bug even
> though a patch was supposedly submitted.  Please let me know if you see
> any
> errors:
> 
> > RH 7.1 uses xinetd-2.1.8.9pre14-6 and here's what I get and I've
> enable
> linuxconf-web via the fabulous chkconfig command:
> >
> > [root seawolf xinetd.d]# netstat -atn | grep 98
> > tcp        0      0 0.0.0.0:98              0.0.0.0:*              
> LISTEN
> 
> Ok, linuxconf-web is enabled and something is listening on port 98.
> Good!
> Now I'll connect to port 98 via a web browser:
> 
> > [root seawolf xinetd.d]# ps -ef | grep linuxconf
> > root     29765 27527 12 09:29 ?        00:00:25 linuxconf --http
> 
> Ok, a linuxconf session was started by xinetd. We have its PID. Good!
> The web browser is waiting for a response from the server.  It will wait
> forever because:
> 
> > [root seawolf xinetd.d]# ls -l /proc/29765/fd/ | grep socket
> > lrwx------    1 root     root           64 May  9 09:31 0 ->
> socket:[18056325]
> > lrwx------    1 root     root           64 May  9 09:31 1 ->
> socket:[18056325]
> > lrwx------    1 root     root           64 May  9 09:31 2 ->
> socket:[18056325]
> > lrwx------    1 root     root           64 May  9 09:31 20 ->
> socket:[18056325]
> > lrwx------    1 root     root           64 May  9 09:31 21 ->
> socket:[18056325]
> 
> Now what really matters is the inode number of the file handle number 0.
> A
> service started by inetd/xinetd always have file handles 0,1,2 opened to
> some socket. For nowait service, this is a data socket (a socket
> connected
> to some client) and for wait service, this is the controlling socket,
> used
> to accept new connections.
> 
> So here we have socket inode number 18056325
> 
> From /proc/net/tcp, we will see which socket is it.
> 
> > [root seawolf xinetd.d]# cat /proc/net/tcp |grep :0062
> >    1: 00000000:0062 00000000:0000 0A 00000000:00000000 00:00000000
> 00000000
> > 0        0 1249910 1 c812d040 300 0 0 2 -1
> >   80: E9236B0C:0062 2D236B0C:0C86 01 00000000:00000111 00:00000000
> 00000000
> > 0        0 18056325 1 c74475c0 300 4 8 2 -1
> 
> Ok, from this output, we see two socket on port 98 (hex 62). We see a
> socket with source and destination address 0.0.0.0:98 0.0.0.0:0. This
> correspond to the listening socket we saw above (output of the netstat
> command). Its inode number is 1249910. This is THE controlling socket.
> 
> The second socket with inode number 18056325 is a data socket showing a
> connection from host 2D236B0C to the server E9236B0C (expressed in
> hexadecimal in network byte order). This is a data socket (a connected
> socket).
> 
> This is what Linuxconf is getting as file handle 0. It can't work.
> Linuxconf wants the other and only xinetd can provide it.
> 
> So xinetd provides the wrong socket.  Clearly an xinetd bug?
> 
> For now the solution is to use xinetd version on
> ftp.solucorp.qc.ca/pub/misc.
> 
> Comments?
> -eric wood
> 
> 
> 
> _______________________________________________
> Redhat-list mailing list
> Redhat-list redhat com
> https://listman.redhat.com/mailman/listinfo/redhat-list


-- 
Everything you know is wrong.  But some of it is a useful first
approximation.