Bug 77653 - xinetd excessive CPU usage
Summary: xinetd excessive CPU usage
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xinetd
Version: 8.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jay Fenlason
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-11-11 15:39 UTC by Terry Riley
Modified: 2014-08-31 23:24 UTC (History)
1 user (show)

Fixed In Version: xinetd-2.3.11-1.8.0
Clone Of:
Environment:
Last Closed: 2003-08-11 17:35:31 UTC
Embargoed:


Attachments (Terms of Use)
network, xinetd information (1.80 KB, text/plain)
2003-04-14 14:51 UTC, Terry Riley
no flags Details
linuxconf-web and sgi_fam info (936 bytes, text/plain)
2003-04-14 16:32 UTC, Terry Riley
no flags Details
xinetd.d output (215 bytes, text/plain)
2003-04-16 21:57 UTC, Terry Riley
no flags Details

Description Terry Riley 2002-11-11 15:39:26 UTC
Description of Problem: xinetd is using 99% of CPU time. 		

Version-Release number of selected component (if applicable):xinetd-2.3.7-2 


How Reproducible: problem occurs after installation is completed. Killing xinetd
removes the excess CPU usage.


Steps to Reproduce:
1.install 8.0 with xinetd included 
2. boot
3. 

Actual Results: xinetd uses 99% of CPU and causes a load average of 1.00


Expected Results: 0% CPU usage; minimal load average


Additional Information: This problem has occurred in the two most recent 8.0
installs from a CD that 
I had run a mediacheck on just prior to the problem installs. Other installs
prior to the mediacheck, on similar machines, didn't create the xinetd problem.

Comment 1 Michael Lee Yohe 2002-11-13 18:10:41 UTC
Can you provide an strace file to see what xinetd is doing on your machine (the
before mediacheck and after mediacheck scenarios)?

# ps ax | grep xinetd
  763 ?        S      0:00 xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid

# strace -p 763 2> output

<< let it run for about 10 seconds >>

CTRL+C

Attach your output file to this bug.

Comment 2 Terry Riley 2002-11-14 20:55:10 UTC
strace output (pre-mediacheck) on working 8.0 machines:

select(6, [3 5], NULL, NULL, NULL <unfinished ...>


strace -p doesn't produce any output on excessive CPU (post-mediacheck) machines

Comment 3 Jay Fenlason 2003-04-09 16:06:30 UTC
What's the network configuration like on the machines that fail?  Also, can you
send me (attach to this bug report) the contents of your /etc/xinetd.conf and
the output of an ls -la of your /etc/xinetd.d directory?  I haven't been able to
reproduce this problem on any of the machines I've tried here.

Comment 4 Terry Riley 2003-04-14 14:51:33 UTC
Created attachment 91123 [details]
network, xinetd information

Comment 5 Jay Fenlason 2003-04-14 15:59:00 UTC
I see two interesting things about your services in /etc/xinetd.d/:
1: I can't find a linuxconf-web file anywhere on my 8.0 CDs.  Can you run "rpm
-q -f /etc/xinetd.d/linuxconf-web" and tell me what package that file is from?
Also, can you attach a copy of it to this bug?
2: your /etc/xinetd.d/sgi_fam file is larger than mine.  Mine matches the one in
our CVS.  Can you attach a copy of your file to this bug?

Can you also try moving both of these files out of /etc/xinetd.d and restarting
xinetd?  If one of these files is the culprit, doing this should cause xinetd to
run normally.

Comment 6 Terry Riley 2003-04-14 16:32:29 UTC
Created attachment 91125 [details]
linuxconf-web and sgi_fam info

Comment 7 Terry Riley 2003-04-14 16:36:45 UTC
Thanks,

sgi_fam is the culprit. It is disabled on the machines with excessive CPU.
Moving it out of xinetd.d solved the problem, so it seems to be the combination 
of present/disabled that is the cause.

linuxconf-web is a holdover from 7.3 apparently.

I'm attaching the rest of the info you asked for.

Terry

Comment 8 Jay Fenlason 2003-04-16 21:15:24 UTC
It looks like linuxconf-web dates back to 7.2.  I can't see in in the 7.3
repository.

Setting up my 8.0 system with the services you have does not trigger the bug
here.  I'm starting to think it's directory entry order related.  Does putting
the original sgi_fam entry back into a formerly-broken system cause it to break
again?  If it does, can you do a "ls -U /etc/xinetd.d" and attach it to this bug?

I'm in the process of releasing an xinetd errata that upgrades it to 2.3.11.  I
don't know if it will have any effect on this problem or not, but it does fix a
lot of others.  If you want to try it, I've put a copy at
ftp://people.redhat.com/~fenlason/.xinetd/xinetd-2.3.11-1.8.0.i386.rpm

Comment 9 Terry Riley 2003-04-16 21:57:00 UTC
Created attachment 91161 [details]
xinetd.d output

Thanks,

Putting sgi_fam back in breaks it again.
Here's the output of ls -U /etc/xinetd.d

-Terry

Comment 10 Jay Fenlason 2003-04-17 19:43:32 UTC
OK.  It's caused by a double-free in sc_free() and get_service_entry().  It's
already fixed in 2.3.11, so please try the rpm I put on people.redhat.com

Comment 12 Jay Fenlason 2003-08-11 17:35:31 UTC
AFAICT this was fixed by the xinetd-2.3.11-1.8.0 erratum. 


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