How to prevent gam_server from running?

docblue at
Tue Apr 3 08:12:17 UTC 2012


<gam_server> is not a "system-level" service per se : it is not started via
a well-defined /etc/rc.d/xxx or /usr/local/etc/rc.d script.

Contrary to that, it is a "user-level" service started on-demand by other
mechanisms, most often desktop related. Like polkit stuff.

Therefore, it is not <gam_server> per se which is responsible for intensive
CPU consumption, but rather whatever mechanism services higher in the stack
that are launching it on their behalf to monitor files/directories activity.

For instance, konqueror, dolphin, as well as many other file-related desktop
apps, launch a <gam_server> instance to monitor on their behalf what's going
on wherever they are looking at, so they can reflect file/dir changes in
(almost) real-time. So they do not do polling themselves.

What I did in my system (a PC-BSD running KDE) was to chmod o-rx any
executable file related to polkit, akonadi, nepomuk, striggi, virtuoso :  

 find -x / -type f  -perm +0111 \( -name '*polkit*' -or -name '*nepomuk*'
... \) -print0 | xargs -0 chmod a-rx {} \;

Then I would stop any remaining unnecessary running service.

This served quite well for me, and things got much much better, though I
never checked wether the apps were happy or not about my violent command. As
a buzzy developer, I should confess that I do not care too much at all about
most of the desktop apps (be KDE or Gnome), and mostly enjoy resorting to
using Firefox, Thunderbird, Libreoffice, Evince and Konsole (I have loved
this one for almost a decade) where I run tabs and Vim :) (I mostly never
use any file wiewer, konqueror or Dolphin). 

So your mileage may vary !

In all case, please refrain from applying shutting down the gam_server file
itself, or you will end-up having a really unusable system. It's better IMO
to apply a fine-grained control wherever and as much as possible,
identifying which app uses <gam_server> and decide on a case by case
approach what to do. Of course, this is a tedious time-consuming
unproductive job, but the price is a smoother  system.


Franck Porcher  


View this message in context:
Sent from the freebsd-questions mailing list archive at

More information about the freebsd-questions mailing list