UNIX for Advanced & Expert Users

I wonder if anyone could assist with some problems I'm having with Linux Capabilities and their use when using the commands "nice" and "schedtool".

I run a couple of PCs, one is an elderly AMD Sempron 2800+ (32-bit, 2GHz clock and 3GB memory) that is used as a family multimedia system running mythTV. The other is an AMD Phenom II X3 (64-bit, three core, 2.5GHz, 4GB memory). Both systems run Ubuntu 10.04 LTS 32-bit and 64-bit versions respectively.

Ever since upgrading both systems to 10.04 I have had persistent, initially severe stuttering audio when using Rhythmbox and, on the media PC only, lesser problems with stuttering TV playback with mythTV. When I reverted from pulseaudio to ALSA, the severe problems with rhythmbox were cured on the desktop PC and alleviated on the media PC.

I am now attempting deal with the remaining problems on the media PC and, using rhythmbox as a guinea pig, I would like to try running rhythmbox either with a lower nice setting or scheduled as a real time process (SCHED_RR).

I wrote a (very short) script containing "nice --adjustment=-10 rhythmbox", gave the script execute and setuid root priviledges and called it. Gnome objected to this telling me that, as a matter of policy, gnome will not run any process as root.

Further research suggested that I needed instead to give the script file the capability cap_sys_nice+eip. The script's nice call was rejected due "insufficient privilege".

I've therefore written the following trivial script, test-file-caps:

Code:

#! /bin/bash
# simple script to trial file capabilities.

echo
echo "nice replies: "
nice --adjustment=-10 rhythmbox
echo
echo "capsh replies: "
/sbin/capsh --print

and here is an example of it's use. You will see that despite the file having the cap_sys_nice capability, that capability is not present when it executes.

Code:

mike@orion:~/scripts$ ls -l ./test-file-caps
-rwxr--r-- 1 mike mike 167 2012-02-08 16:12 ./test-file-caps
mike@orion:~/scripts$ getcap ./test-file-caps
./test-file-caps = cap_sys_nice+eip
mike@orion:~/scripts$ ./test-file-caps

nice replies: 
nice: cannot set niceness: Permission denied

capsh replies: 
Current: =
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,
cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,
cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,
cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,
cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,
cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,
cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,
cap_mac_admin
Securebits: 00/0x0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
uid=1000
mike@orion:~/scripts$

Can anyone please give me any suggestions or pointers to information that I'm lacking.

Priority is not a "go faster" button. Increased priority isn't going to do a lot on an idle system.

My suggestion would be to revert to what you had before, or consider what scheduling options you have set in your kernel.

Thanks Corona,

The system normally has about 180 processes active but despite this the processor utilisation rarely exceeds 30% to 40% of which rhythmbox is only a few percent. Rhythmbox works except that every 30 seconds to one minute the sound "glitches".

I have spent a considerable amount of time eliminating/fixing other issues with it and am now left with this residue of infrequent glitches. My current working hypothesis is that occasionally the demands of some other process briefly blocks rhythmbox from the processor causing a buffer underrun. This hypothesis is supported by the fact that on the significantly more powerful processor there is no glitching.

On the basis that the processing demands of Rhythmbox are slight and that it's probably the most time-critical application running, I thought it might be instructive to see what a higher priority might achieve.

tldnr; I'm not really using it as a go faster button, I'm hoping it will be a latency reduction mechanism.

If you can figure out what might be interrupting it, nice it instead. It takes no special permissions to reduce the priority of something. You can even lower the priority of a process after the fact with renice, though then it does need root...