Bug 22889

Have you enabled ipop3 (disabled by default)?  Use ntsysv to enable it.  Are you
trying to telnet as root?

The services work fine for maybe 2 hours and then just lock up.
I have never had any xinetd work for over a day.  I am currently
using the old inetd super server.  I generally use chkconfig to
enable services.

Here is my latest xinet configuration for ipop3
service pop3
{
        socket_type             = stream
        wait                    = no
        user                    = root
        server                  = /usr/sbin/ipop3d
}

I tried changing some logging options to see if that would help,
but lockups still occurred.

Do you have the same problems with the released  xinetd? DLT, can you try get a
load test of this?

I was under the impression that this problem was similar to bug 19355.
I have tried the released versions for 7.0 and get similar results.

Do you use /etc/hosts.{allow,deny}? Try removing these files, and use the
"only_from" syntax instead... Also, try stracing the process when this happens,
see if you have many concurrently running servers and add the "-d" option to xinetd.

I ran 20 clients using fetchmail to a server which was generating mail at a rate
of 1/sec.  The clients
were using fetchmail in demon mode every 2 seconds (also at 1 second).  I
couldn't get xinetd to lock up at all.  I repeated the experiment using imap. 
Still no lockup.  Both of these test cases cause the server to achieve a load
average of 5.0 - 6.0.  

Without more information, I can't reproduce this.

As we can't reproduce this in our own load tests, I'm closing this.

Ok, it finally repeated itself.  It took someone to travel back out to a remote
site and try to get mail.  When they do try to access the pop server, the entire
pop server hangs.  Even telnet hangs for LAN users at

Trying 216.250.91.35...
Connected to CatInTheHat.kaivo.com (216.250.91.35).
Escape character is '^]'.

I do not as of yet know the details of the remote site.  All I currently know is
that all day people have been complaining of their mail app hanging when
checking mail.

I use hosts.allow/deny due to the use of at least SSH and portmap.  I cannot do
away with them.

What is the load mix when this happens? Can you try pre14, which should fix a
couple of minor issues and make tcp_wrapper handling more efficient?

Had a chance to try the new xinetd rpm yet?

I am currently using it.  Sometimes it errors out with:

xinetd[13779]: execv( /usr/sbin/ipop3d ) failed: Bad address (errno = 14)

A restart seems to take care of it for the moment.

We have not had anyone go back yet to the customer's location where the problem
occurs.  Therefore, I have not seen the problem occur again.

The latter was a problem with the envp not being terminated properly, and has
been fixed - the primary problem should be fixed as well, reopen if you find it
isn't.

Now with xinetd-2.1.8.9pre14-5 I get a slightly different problem.  It seems at
least the xinetd process is no longer being blocked so that people can still
retrieve mail.  The problem is now just with the single connection getting stuck
while connecting.  Here is how telnet looks:

Trying 192.168.0.1...
Connected to popserver (192.168.0.1).
Escape character is '^]'.

Telnet hangs there and does not bring up the +OK POP3 reply before the mail
client times out.

I am currently back to using the old inetd superserver again.

Does reverse DNS lookup on the client work? Can you try removing the
identification information in the options (does it try to talk to the identd?

Reverse lookup appears to work.  It looks like it is some CIDR delegated block.

I initially changed /etc/hosts.allow from ALL@ALL to ALL for the service.  It
seemed like that took care of the problem.  Afterward, I removed the
log_on_failure line from the ipop3 xinetd configuration file as well.  That
seemed to have no effect.

Is this a known misconfiguration on my part?  As long as it is documented, I am
now happy with xinetd.

The fact that things improved after changing ALL@ALL to ALL would 
seem to indicate that it was an auth lookup problem.  The curious part is 
that ALL@ALL worked with inetd, but not with xinetd.  That is very strange.
There are numerous records of my rants about why auth/ident is stupid 
and should not be used at all.
Since the demo you've given us is a designated non-routable address, I'll 
assume that you're using this address range internally and you have DNS 
properly setup to respond to forward and reverse lookups for the address 
space.

The server does have a routable address.  I just threw in a fake one.  As far as
I know, DNS is setup correctly.  In my case, I really was overusing ident.  It
was not needed even for debugging.

Local configuration issue - closing as "RAWHIDE" for the original solution.