Bug 75055 - gnome fails to run due to sgi_fam
gnome fails to run due to sgi_fam
Status: CLOSED DUPLICATE of bug 74696
Product: Red Hat Linux
Classification: Retired
Component: fam (Show other bugs)
8.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Alexander Larsson
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-03 20:49 EDT by Need Real Name
Modified: 2015-01-07 19:00 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-10-03 21:14:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2002-10-03 20:49:01 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830

Steps to Reproduce:
1. switchdesk-helper GNOME
2. startx

Actual Results:  The small red hat window was displayed with none of the icons
underneath and a black background.  Nothing else happens until X is killed. 
/var/log/messages is littered with lines like the following:

Oct  2 18:28:11 manny xinetd[1774]: warning: can't get
client address: Transport endpoint is not connected
Oct  2 18:28:11 manny xinetd[1774]: libwrap refused connection to sgi_fam from
<no address>
Oct  2 18:28:11 manny xinetd[1775]: warning: can't get client address:
Transport endpoint is not connected
Oct  2 18:28:11 manny xinetd[1775]: libwrap refused connection to sgi_fam from
<no address>

If sgi_fam is disabled then Gnome starts normally.  More info can be had at the
psyche mailing list thread:
https://listman.redhat.com/pipermail/psyche-list/2002-October/000707.html

My system had been upgraded from rh7.3
Comment 1 Alexander Larsson 2002-10-04 12:21:26 EDT

*** This bug has been marked as a duplicate of 74696 ***
Comment 2 Need Real Name 2002-10-06 07:55:14 EDT
Yup same here,
upgrade from rh7.3 to rh8.0. My scenario is as follows (maybe it helps to have a
second scenario). /me start gnome in runlevel 5

1) error notification in /var/log/messages

Oct  6 10:51:11 sahara xinetd[10889]: libwrap refused connection to sgi_fam from
<no address>
Oct  6 10:51:11 sahara xinetd[10890]: warning: can't get client address:
Transport endpoint is not connected

2) Stopped the sgi_fam service in /etc/xinetd.d
3) get this when running gedit

FAMOpen failed, FAMErrno=0

Cheers bernard
Comment 3 Bob Arendt 2002-10-06 16:14:16 EDT
I had the same problem.  In Failsafe, I ran gnome-panel stand-alone
and saw the same problem.  It appears to be a race condition with fam.
Running "./gnome-panel" would usually hang.  Running "gdb ./gnome-panel"
would always succeed (slows down gnome-panel significantly)

Rebuilt the gnome-panel with "-g3 -O2", ran until the hang, then
attached with gdb and got the following stack:

Scattered in g_print()'s , and it hangs in menu-fentry.c in
     if (gnome_vfs_get_file_info
	  (muri, info, GNOME_VFS_FILE_INFO_DEFAULT)
	       != GNOME_VFS_OK) {

#0  0x420cdb84 in write () from /lib/i686/libc.so.6
#1  0x4083eb44 in __JCR_LIST__ () from /lib/i686/libpthread.so.0
#2  0x40d49b54 in completed.1 () from /usr/lib/libfam.so.0
#3  0x40d4c891 in FAMClose () from /usr/lib/libfam.so.0
#4  0x40d4c945 in FAMMonitorDirectory () from /usr/lib/libfam.so.0
#5  0x40d09716 in do_monitor_add () from /usr/lib/gnome-vfs-2.0/modules/libfile.so
#6  0x406b1321 in gnome_vfs_monitor_do_add () from /usr/lib/libgnomevfs-2.so.0
#7  0x406b2579 in gnome_vfs_monitor_add () from /usr/lib/libgnomevfs-2.so.0
#8  0x40cf9fe8 in monitor_setup () from
/usr/lib/gnome-vfs-2.0/modules/libvfolder-desktop.so
#9  0x40cfd1d7 in get_vfolder_info_unlocked () from
/usr/lib/gnome-vfs-2.0/modules/libvfolder-desktop.so
#10 0x40cfd3ca in get_vfolder_info () from
/usr/lib/gnome-vfs-2.0/modules/libvfolder-desktop.so
#11 0x40cfffa3 in do_get_file_info () from
/usr/lib/gnome-vfs-2.0/modules/libvfolder-desktop.so
#12 0x4069e28c in gnome_vfs_get_file_info_uri_cancellable () from
/usr/lib/libgnomevfs-2.so.0
#13 0x406b1cb5 in gnome_vfs_get_file_info_uri () from /usr/lib/libgnomevfs-2.so.0
#14 0x406b1c66 in gnome_vfs_get_file_info () from /usr/lib/libgnomevfs-2.so.0
#15 0x0809b250 in fr_read_dir (dr=0x406c3078, muri=0x80aa69c "applications:/",
mtime=0, sublevels=2) at menu-fentry.c:416
#16 0x0808fe34 in init_menus () at menu.c:169
#17 0x0806b430 in session_load () at session.c:335
#18 0x0805ace9 in main (argc=-512, argv=0xbffffaa4) at main.c:199
#19 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6


Stopped where it hung in fr_read_dir()
(gdb) p muri
$1 = 0x80aa69c "applications:/"
(gdb) p *info
$3 = {name = 0x1 <Address 0x1 out of bounds>, valid_fields = 135118184, type =
GNOME_VFS_FILE_TYPE_UNKNOWN, 
  permissions = 135108008, flags = 1087387776, device = 580274477103841280,
inode = 135108240, link_count = 0, uid = 0, 
  gid = 0, size = 171798691872, block_count = 73149552272, io_block_size =
1107326060, atime = 1108521492, 
  mtime = 1869506351, ctime = 17, symlink_name = 0x4212003c "", mime_type =
0x4212b1dc "", refcount = 1819632751, 
  reserved1 = 0x11, reserved2 = 0x4200746c, reserved3 = 0x4212b1f4, reserved4 =
0x65642d72, reserved5 = 0x11}
(gdb) p/x *info
$4 = {name = 0x1, valid_fields = 0x80dbd68, type = 0x0, permissions = 0x80d95a8,
flags = 0x40d03880, 
  device = 0x80d8c9000000000, inode = 0x80d9690, link_count = 0x0, uid = 0x0,
gid = 0x0, size = 0x2800000020, 
  block_count = 0x11080d9690, io_block_size = 0x4200746c, atime = 0x4212b214,
mtime = 0x6f6e672f, ctime = 0x11, 
  symlink_name = 0x4212003c, mime_type = 0x4212b1dc, refcount = 0x6c75646f,
reserved1 = 0x11, reserved2 = 0x4200746c, 
  reserved3 = 0x4212b1f4, reserved4 = 0x65642d72, reserved5 = 0x11}
(gdb) p *dr
$6 = {frec = {type = 220956, name = 0x40654268 "", comment = 0x4000a180
"PQR\213T$\020\213D$\f&#65533;\200&#65533;&#65533;&#65533;ZY\207\004$&#65533;\b", 
    fullname = 0x40695f72 "h", name_collate_key = 0x40897520 "U\211&#65533;\203&#65533;\030
\211]&#65533;\213U\b\215E\f&#65533;\020Y&#65533;&#65533;\201&#65533;p2\003", 
    icon = 0x40695f92 "h\020", exec = 0x40695fa2 "h\030", tryexec_path =
0x40695fb2 "h ", parent = 0x40695fc2, 
    mtime = 1080647634, last_stat = 1080647650}, ditemmtime = 1080647666,
ditemlast_stat = 1080647682, tryexecs = 0x40696012, 
  recs = 0x40696022, mfl = 0x406a6db0}
(gdb) p/x *dr
$7 = {frec = {type = 0x35f1c, name = 0x40654268, comment = 0x4000a180, fullname
= 0x40695f72, name_collate_key = 0x40897520, 
    icon = 0x40695f92, exec = 0x40695fa2, tryexec_path = 0x40695fb2, parent =
0x40695fc2, mtime = 0x40695fd2, 
    last_stat = 0x40695fe2}, ditemmtime = 0x40695ff2, ditemlast_stat =
0x40696002, tryexecs = 0x40696012, recs = 0x40696022, 
  mfl = 0x406a6db0}
(gdb) 


Nautilus didn't seem to have this problem using fam, only gnome-panel.

Looks like the problem is really down in gnome-vfs and it's interaction
with fam.  Probably related to the gnome-vfs deadlock noted in bug 86254

http://bugzilla.gnome.org/show_bug.cgi?id=86254

Hope this helps,
-Bob Arendt
Comment 4 Alexander Larsson 2002-10-07 04:55:55 EDT
rda: I would say you aren't having the same problem. If you get the libwrap
warnings you won't ever connect to fam, and therefore you won't be able to add
any fam monitor and therefore not deadlock.

I also wonder why you got the deadlock. You have to monitor about 200 dirs
without ever idling inbetween in order to get it.
Comment 5 Bob Arendt 2002-10-07 11:08:07 EDT
Agreed, not the same problem .. but title fits fits the symptom
exactly - with sgi_fam present gnome fails to run.
Doing a 'ls -1 |wc -l' in HOME yields 354 dirs+files.  Does nautilus
try to monitor all files?  Also, it seems nautilus comes up but
login freezes on gnome-panel (in fact without nautilus (running FailSafe
session), gnome-panel can freeze in this manner).  And it's only during
gnome-panel startup.  If I run gnome-panel using gdb, it always succeeds.
Please feel free to shift this to a more appropriate bug, but there's
certainly a flaw in the interaction.
Please let me know if there's any rebuild/debug I should try.
Right now my workaround is to add "disable=yes" to /etc/xinetd.d/sgi_fam.
-Bob Arendt
Comment 6 Alexander Larsson 2002-10-08 10:09:09 EDT
I filed the deadlock issue as bug 75425

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