Bug 59523 - fam/nautilus problem
Summary: fam/nautilus problem
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: xinetd
Version: skipjack-beta1
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact:
URL:
Whiteboard:
: 62289 62515 (view as bug list)
Depends On:
Blocks: 61901
TreeView+ depends on / blocked
 
Reported: 2002-02-09 11:42 UTC by Chris Runge
Modified: 2008-05-01 15:38 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-04-08 14:13:18 UTC
Embargoed:


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

Description Chris Runge 2002-02-09 11:42:42 UTC
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):

fam-2.6.7-4
nautilus-1.0.6-5

How Reproducible:

very

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 11:43:19 UTC
oh, this is hampton beta 1, just to be clear

Comment 2 Brent Fox 2002-02-09 17:47:06 UTC
I'm seeing this with every install I've done so far.

Comment 3 David L. Parsley 2002-02-10 02:35:07 UTC
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 16:14:38 UTC
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 16:16:06 UTC
I'm cc:ing trond on this, since he owns xinetd.


Comment 6 Alexander Larsson 2002-04-04 19:59:21 UTC
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 20:00:12 UTC
Created attachment 52244 [details]
Patch for xinetd that solves the problem

Comment 8 Alexander Larsson 2002-04-04 20:01:10 UTC
*** Bug 62515 has been marked as a duplicate of this bug. ***

Comment 9 Alexander Larsson 2002-04-04 20:04:26 UTC
*** Bug 62289 has been marked as a duplicate of this bug. ***

Comment 10 Alexander Larsson 2002-04-04 20:07:59 UTC
Moving over should-fix status from dup.

Comment 11 Daniel Resare 2002-04-07 18:33:19 UTC
I can report success with this problem when using xinetd-2.3.4-0.8 from rawhide

Comment 12 Gene Czarcinski 2002-04-08 14:07:37 UTC
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 14:13:14 UTC
Another note -- the problem goes away after reboot but appears again after
logout/login.


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