Bug 59523 - fam/nautilus problem
fam/nautilus problem
Product: Red Hat Public Beta
Classification: Retired
Component: xinetd (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
: 62289 62515 (view as bug list)
Depends On:
Blocks: 61901
  Show dependency treegraph
Reported: 2002-02-09 06:42 EST by Chris Runge
Modified: 2008-05-01 11:38 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-08 10:13:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch for xinetd that solves the problem (365 bytes, patch)
2002-04-04 15:00 EST, Alexander Larsson
no flags Details | Diff

  None (edit)
Description Chris Runge 2002-02-09 06:42:42 EST
Description of Problem: 

The problem exhibits itself in nautilus, but I think I've traced it to fam.
Basically, after starting GNOME once the Nautilus desktop will come up.
Subsequent exits and restarts of GNOME often fail to start the Nautilus desktop.
Furthermore it is impossible to start the Nautilus file manager. In addition,
when this happens I am unable to use the GNOME logout feature--I must
CTRL-ALT-BACKSPACE. I've done some investigation and noticed that this only
seems to happen when fam is defunct in ps, i.e., ps -aex shows something like this

 1237 ?        Z      0:00 [fam <defunct>]

Issuing the command service xinetd restart seems to fix the problem, such that
when GNOME is restarted Nautilus does start as usual again.

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


How Reproducible:


Steps to Reproduce:
1. start GNOME, exit
2. start GNOME (did Nautilus start?; if so exit)
3. start GNOME (Nautilus almost surely will not have started by this point)

Actual Results:

Expected Results:

Additional Information:
Comment 1 Chris Runge 2002-02-09 06:43:19 EST
oh, this is hampton beta 1, just to be clear
Comment 2 Brent Fox 2002-02-09 12:47:06 EST
I'm seeing this with every install I've done so far.
Comment 3 David L. Parsley 2002-02-09 21:35:07 EST
I think this might be a problem with xinetd, which may have poor support for RPC
services.  I downgraded to xinetd from 7.2, and it seems to have fixed it.
Comment 4 Alexander Larsson 2002-02-11 11:14:38 EST
Hmm. Haven't seen this yet on my system, but it I wouldn't be supprised at all
if xinetd is the culprit. The support for wait rpc services is not widely used,
and has caused trouble before.
Comment 5 Alexander Larsson 2002-02-11 11:16:06 EST
I'm cc:ing trond on this, since he owns xinetd.
Comment 6 Alexander Larsson 2002-04-04 14:59:21 EST
This is actually a xinetd problem. It fails to reap the fam child if there are
no other services that xinetd handles.
Comment 7 Alexander Larsson 2002-04-04 15:00:12 EST
Created attachment 52244 [details]
Patch for xinetd that solves the problem
Comment 8 Alexander Larsson 2002-04-04 15:01:10 EST
*** Bug 62515 has been marked as a duplicate of this bug. ***
Comment 9 Alexander Larsson 2002-04-04 15:04:26 EST
*** Bug 62289 has been marked as a duplicate of this bug. ***
Comment 10 Alexander Larsson 2002-04-04 15:07:59 EST
Moving over should-fix status from dup.
Comment 11 Daniel Resare 2002-04-07 14:33:19 EDT
I can report success with this problem when using xinetd-2.3.4-0.8 from rawhide
Comment 12 Gene Czarcinski 2002-04-08 10:07:37 EDT
This is still occuring in skipjack beta2.  It would be helpful if there was an
up2date channel for skipjack-beta2 and this fix was available.
Comment 13 Gene Czarcinski 2002-04-08 10:13:14 EDT
Another note -- the problem goes away after reboot but appears again after

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