Saturday Jun 14, 2008

How to keep gam_server from doing too much

The Gamin file monitoring subsystem was introduced to OpenSolaris a few months ago. Since it monitors file changes, there are cases where it can become very busy and consume significant system resources. Most of the resource consumption issues will probably be fixed by build 92, but for those of us running OpenSolaris 2008.05 or Nevada builds before build 92, or those of us with special requirements such as remote NFS mounted home directories, AlekZ's Scratchpad has a very nice workaround to put gam_server back in its place. I'd recommend the following slightly modified workaround:

   1. Create /etc/gamin directory:
      # mkdir /etc/gamin

   2. Create file /etc/gamin/gaminrc. It may contain the following lines (this is just an example, you can set your own polling intervals):
      fsset nfs poll 15
      fsset ufs poll 15
      fsset lofs poll 15
      fsset zfs poll 15

   3. Restart gam_server (let me know if there is a better way):
      # pkill gam_server ; rm -rf /tmp/gam_\*
    

Friday Mar 14, 2008

Workaround for nautilus/panel crashes in Nevada 84, 85.

A number of people have encountered a bug which causes nautilus and panel to crash on login, preventing the desktop from being used.

The symptoms are:
  • Nautilus crashes immediately on login, bringing up bug-buddy dialog.
  • Panel crashes immediately after the user clicks the Launch menu.
  • Any application which makes use of gtk icons crashes.

The bug is only experienced on some hardware and may not occur on every install even on hardware where it fails. It is caused by a file access race condition during the post install phase. The file access conflict causes an ASSERT in the gtk-update-icon-cache which forces this application to core during install. The user is left with incomplete and corrupt icon cache which causes failures of all applications depending on the gtk icon cache.

The bug is described in more detail here: 6631419 - gtk-update-icon-cache dies on first boot after install/upgrade

Fortunately, there is a very simple workaround:
  • Login as root
  • Run the following:
    for d in /usr/share/icons/\*; do
           [ -d $d ] &&
                   gtk-update-icon-cache --force $d;
    done
    

This bug is intermittent and is known to exist in Nevada build 84 and build 85. It may exist in earlier builds on some hardware. The GNOME community's decision to enable application cores on ASSERT may have made some of these subtle underlying problems suddenly become much more frequent and obvious. A fix for bug 6631419 is committed for Nevada build 86.

CORRECTION: There was a discussion over enabling fail on assert within the GNOME community, but no change was recently made. The behavior is that on unstable (odd numbered) versions of gnome-session, fail on assert is enabled, but on even numbered builds it isn't.

About

bnitz

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today