Rahul Bhargava on Evolphin & Technology

When you install Fedora Core, it appears the beagle indexing service is started in the background automatically. On my machine, beagle was consuming too many resources. In order to stop the damn thing, I had to tear my hairs!

The beagle daemon for one is not installed as a normal /etc/init.d or xinetd service. The following recipe worked for me, might need to scipt it and launch it from the bashrc when loggin in:

1. $ beagled –disable-schedule ( this would disable the scheduler)
2. $ beagle-settings (This brings up a GUI to stop it from indexing, just deselect the options, see the screen shot below)
   
3. $ beagle-shutdown (now the damn service should be gone)
4. $ beagle-info –status
   Could not connect to the daemon.

If you see the last line, you are set!

The fabolous thing about upgrading to Fedora Core 6 has been that the yum package manager now routinely hangs on my machine. This does not make for a fun experiecne. For me it typically hangs hard after a pop-up message:

Retreiving software information

A little bit of detective work in another terminal indicates why:

# ps -leaf | grep `cat /var/run/yum.pid`

This number is Pirut’s yum process ID. Let’s see what it’s stuck doing:

# strace -p `cat /var/run/yum.pid
[root@rahul ~]# strace -p 2524
Process 2524 attached – interrupt to quit
ioctl(4, FIONREAD, [0])                 = 0
poll( <unfinished …>

Check, this out; it is waiting in a poll system call. This usually implies that the process is waiting for a network IO event to happen. If the previous pirut process is gone, well, things can get to this mess. By the way, it is possible to nuke pirut yum at this point; you just have to be brutal.

# pkill -9 pirut

Once this is done, a little digging around often shows a couple of __db.* files in /var/lib/rpm. Let’s nule all of these:

# rm -rf /var/lib/rpm/__db.*

At this juncture, retrying the hung yum/pirut command should work. At least, it does so for me. Sometimes, I need to run “yum clean all” after cleaning up the above mess before yum can make progress.

THE PROBLEM

CVS allows you tp specify a run-as user-name in the CVSROOT/passwd file. So for example if we use the following syntax in CVSROOT/passwd file:

john:12$2#&65:cvsadmin
greshim:ac2$2#&65:cvsadmin

The above tells the CVS server to launch/fork the CVS process with the effective user-id as ‘cvsadmin‘ instead of say CVS user ‘john‘ who may have executed the commit command. This allows the CVS administrator to maintaina separation between system user and the CVS user. It allows the admin to avoid polluting UNIX file level permissions inside the CVSROOT.

However the problem is how does a CVS trigger like Loginfo get hold of the actual CVS user on whose behalf the run-as user is executing the CVS command ? If the trigger script uses ‘whoami’ to query the user it would get the effective user-id like ‘cvsadmin’ instead of ‘john’.

THE SOLUTION

Read the rest of this entry »