Bug 112671 - xinetd takes all cpu resources
Summary: xinetd takes all cpu resources
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xinetd
Version: 9
Hardware: athlon
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jay Fenlason
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-12-27 12:50 UTC by Heinz Ruffieux
Modified: 2014-08-31 23:25 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-03-22 20:15:46 UTC
Embargoed:


Attachments (Terms of Use)

Description Heinz Ruffieux 2003-12-27 12:50:42 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.2.1)
Gecko/20030225

Description of problem:
When starting xinetd using command "/etc/rc.d/init.d/xinetd start"
xinetd works fine, but takes all cpu resources (checked with command:
top).

Content of /etc/xinetd.conf file:

#
# Simple configuration file for xinetd
#
# Some defaults, and include /etc/xinetd.d/
                                                                     
          
defaults
{
        instances               = 60
        log_type                = SYSLOG authpriv
        log_on_success          = HOST PID
        log_on_failure          = HOST
        cps                     = 25 30
}
                                                                     
          
includedir /etc/xinetd.d



Version-Release number of selected component (if applicable):
xinetd-2.3.11-1.8.0

How reproducible:
Always

Steps to Reproduce:
1. start xinetd
2.
3.
    

Actual Results:  xinet works, but takes all cpu resources

Expected Results:  work but using minimal cpu resources

Additional info:

Comment 1 Steve Grubb 2005-03-22 19:02:18 UTC
I'm the upstream maintainer of Xinetd. Does xinetd still do this? Did you have
any services using xinetd such as sgi_fam? Send xinetd a SIGUSR1 to get it to
dump its state. Look for the file /var/run/xinetd.dump and attach it.

If this is not reproducible, I'd say this could be closed as not a bug.


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