Bug 77653
Summary: | xinetd excessive CPU usage | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Terry Riley <terrence> | ||||||||
Component: | xinetd | Assignee: | Jay Fenlason <fenlason> | ||||||||
Status: | CLOSED ERRATA | QA Contact: | Brock Organ <borgan> | ||||||||
Severity: | medium | Docs Contact: | |||||||||
Priority: | medium | ||||||||||
Version: | 8.0 | CC: | jfeeney | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | i386 | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | xinetd-2.3.11-1.8.0 | Doc Type: | Bug Fix | ||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2003-08-11 17:35:31 UTC | Type: | --- | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Attachments: |
|
Description
Terry Riley
2002-11-11 15:39:26 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. 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 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. Created attachment 91123 [details]
network, xinetd information
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. Created attachment 91125 [details]
linuxconf-web and sgi_fam info
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 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 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
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 The correct URL is ftp://people.redhat.com/fenlason/.xinetd/xinetd-2.3.11-1.8.0.i386.rpm or http://people.redhat.com/fenlason/.xinetd/xinetd-2.3.11-1.8.0.i386.rpm AFAICT this was fixed by the xinetd-2.3.11-1.8.0 erratum. |