Date: Fri, 20 Jun 2008 09:37:48 -0700 From: Frank Jahnke <jahnke@sonatabio.com> To: Joe Marcus Clarke <marcus@marcuscom.com> Cc: freebsd-gnome@freebsd.org Subject: Re: Gnome 2.22: Daemons gone wild Message-ID: <1213979869.985.11.camel@pinot.fmjassoc.com> In-Reply-To: <1213978896.38700.9.camel@shumai.marcuscom.com> References: <1213806747.4251.10.camel@pinot.fmjassoc.com> <1213978896.38700.9.camel@shumai.marcuscom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for the reply! On Fri, 2008-06-20 at 12:21 -0400, Joe Marcus Clarke wrote: > Hald has a special startup script which causes it to spin waiting for > the gettys to be started. When it detects they are running, then it > starts up. This loop will only last 60 seconds. So, if it takes longer > than 60 seconds between when hald is started and init is run, then hald > will not come up at boot time. I will try to give it a longer time before I check hal. Earlier, though, there were no issues. Is there an ordering in rc.conf that makes any difference for this? > You can edit the hald script, and change > line 69 to make the number of loop iterations longer, or figure out why > your system is being so slow. I will give that a try. I've no idea what to check for to debug this. > > Bonobo-activation-server should not be CPU intensive at all. You might > try ktrace'ing it to find out what it is doing. I don't use tracker or > pdftotex, so I can't comment on them. Well, I don't use tracker or pdftotex, at least not in a start-up script. That's what was confusing. See also below. > > > > > Adding the clock to the top panel causes is unsuccessful, though adding > > it after gnome loads works on the second try (the first attempt also > > crashes). Sometimes that audio volume loads; sometimes it does not. > > I have been looking at this for a while. > Edit /usr/local/share/PolicyKit/policy/org.gnome.clockapplet.mechanism.policy, and remove all of the localized lines (those with xml:LANG). See if that helps. > I did find a syntax error in rc.conf that was brought out by moving the mouse entries before the gnome initialization. That took care of the clock and volume-control issues (bonobo and pdftotex too). So that seems to be resolved. It is interesting that I have used this rc.conf file for about five years, and the problem only came out now. hal still does not start, and tracker does (and it should not). I've another odd problem that may or may not be related: some things get swapped out into virtual memory even though there is plenty of free memory (typically, 1 to 1.5GB out of 3 total). Memory, CPU under stress and disks check out fine with the usual tests. The only way to clear it is to reboot -- namely, exiting X11 to the console does not clear the swap file. This sort of debugging is new to me: where do I start? And thanks again for the help. Frank
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1213979869.985.11.camel>