Bug 22889 - xinetd locks services
Summary: xinetd locks services
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: xinetd   
(Show other bugs)
Version: 1.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2000-12-27 18:43 UTC by Need Real Name
Modified: 2007-04-18 16:30 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-02-27 00:20:27 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Need Real Name 2000-12-27 18:43:00 UTC
xinetd will lock and not start any services.  The main
service used is ipop3.  When it happens, the telnet server
will not startup and users cannot retrieve mail.  There are
around 15-20 people hitting the pop server in varying frequencies.

This is a RedHat 7.0 system with updates
and xinetd- installed.

Comment 1 Derek Tattersall 2000-12-27 19:36:02 UTC
Have you enabled ipop3 (disabled by default)?  Use ntsysv to enable it.  Are you
trying to telnet as root?

Comment 2 Need Real Name 2000-12-27 20:42:50 UTC
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.

Comment 3 Trond Eivind Glomsrxd 2000-12-28 00:05:12 UTC
Do you have the same problems with the released  xinetd? DLT, can you try get a
load test of this?

Comment 4 Need Real Name 2000-12-28 00:41:40 UTC
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.

Comment 5 Trond Eivind Glomsrxd 2000-12-28 11:00:36 UTC
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.

Comment 6 Derek Tattersall 2000-12-29 18:28:07 UTC
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.

Comment 7 Trond Eivind Glomsrxd 2001-01-09 19:53:29 UTC
As we can't reproduce this in our own load tests, I'm closing this.

Comment 8 Need Real Name 2001-01-10 00:58:15 UTC
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

Connected to CatInTheHat.kaivo.com (
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.

Comment 9 Trond Eivind Glomsrxd 2001-01-20 23:24:16 UTC
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?

Comment 10 Trond Eivind Glomsrxd 2001-01-31 01:19:40 UTC
Had a chance to try the new xinetd rpm yet?

Comment 11 Need Real Name 2001-02-01 16:53:32 UTC
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.

Comment 12 Trond Eivind Glomsrxd 2001-02-16 19:34:46 UTC
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

Comment 13 Need Real Name 2001-02-26 18:17:22 UTC
Now with xinetd- 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:

Connected to popserver (
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.

Comment 14 Trond Eivind Glomsrxd 2001-02-26 22:50:46 UTC
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?

Comment 15 Need Real Name 2001-02-26 23:41:30 UTC
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.

Comment 16 Rob Braun 2001-02-26 23:58:58 UTC
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 

Comment 17 Need Real Name 2001-02-27 00:20:23 UTC
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.

Comment 18 Trond Eivind Glomsrxd 2001-02-27 06:01:22 UTC
Local configuration issue - closing as "RAWHIDE" for the original solution.

Note You need to log in before you can comment on or make changes to this bug.