rtkit requires a kernel patch

Architecture: i386
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: rtkit 0.4-0ubuntu2
PackageArchitecture: i386
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=fr_FR.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-7.27-generic
Uname: Linux 2.6.31-7-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

Same warning here

karmic
rtkit-daemon

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu karmic (development branch)
Release: 9.10
Codename: karmic

aparantly when i start armagetron processing goes up 200% and it stays even after I close armagetron (armagetron.real keeps running)

Oct 3 11:58:08 quark acpid: client connected from 1235[0:0]
Oct 3 11:58:11 quark console-kit-daemon[1064]: WARNING: Couldn't read /proc/1038/environ: Failed to open file '/proc/1038/environ': No such file or directory
Oct 3 11:58:17 quark rtkit-daemon[1887]: Sucessfully called chroot.
Oct 3 11:58:17 quark rtkit-daemon[1887]: Sucessfully dropped privileges.
Oct 3 11:58:17 quark rtkit-daemon[1887]: Sucessfully limited resources.
Oct 3 11:58:17 quark rtkit-daemon[1887]: Canary thread running.
Oct 3 11:58:17 quark rtkit-daemon[1887]: Failed to make ourselves RT: Invalid argument
Oct 3 11:58:17 quark rtkit-daemon[1887]: Watchdog thread running.
Oct 3 11:58:17 quark rtkit-daemon[1887]: Running.
Oct 3 11:58:18 quark rtkit-daemon[1887]: Failed to make ourselves RT: Invalid argument
Oct 3 11:58:18 quark rtkit-daemon[1887]: Failed to make ourselves RT: Invalid argument

rtkit is installed by default for Karmic and this patch has been known about for a few months.

I think either the patch should be incorporated (I am using Linux eve 2.6.31-11-generic #38-Ubuntu SMP Fri Oct 2 11:55:55 UTC 2009 i686 GNU/Linux from linux-image-2.6.31-11-generic) or rtkit should not be part of the default install of ubuntu-desktop.

(rtkit should probably depend also depend upon the minimal kernel version that allows it to work correctly too).

The commit in question appears to have landed in 2.6.32:

commit ca94c442535a44d508c99a77e54f21a59f4fc462
Author: Lennart Poettering <email address hidden>
Date: Mon Jun 15 17:17:47 2009 +0200

    sched: Introduce SCHED_RESET_ON_FORK scheduling policy flag

    This patch introduces a new flag SCHED_RESET_ON_FORK which can be passed
    to the kernel via sched_setscheduler(), ORed in the policy parameter. If
    set this will make sure that when the process forks a) the scheduling
    priority is reset to DEFAULT_PRIO if it was higher and b) the scheduling
    policy is reset to SCHED_NORMAL if it was either SCHED_FIFO or SCHED_RR.

After a quick look at the code, it appears to me that even though we added rtkit to main, and the daemon now is always started by default, the lack of the SCHED_RESET_ON_FORK flag means that rtkit is not able to actually enable RT scheduling for Pulse Audio? If so that seems pretty broken to me... ( in addition to generating lots of daemon.log noise ).

Note we *could* patch rtkit to not use the flag, however the SCHED_RESET commit explains that it's purpose is to prevent RT scheduling from leaking to child processes which could be seen as a security risk ( see the commit for more details ).

I sent the patches for this to the kernel team a month or so ago, and they didn't want to put them in that late into the cycle, especially since there was no knowing whether they would land for 2.6.32. Now they are in 2.6.32, I still don't think the kernel guys would take them on, considering what they change.

Yup, I saw the email and discussed it with the kernel team while at Plumber's.

What I'm concerned about is the fact that we've introduced a new system daemon which always runs, which is prevented from doing it's actual task ( ie. enabling PA to use RT scheduling ).

I'd like to get a read from the kernel team on what they think. As I pointed out, it *is* possible to patch rtkit to remove the parameter, however from a security perspective that might not be ideal.

Or, we can drop pulseaudio's dependency on it for now.

Just discussed with the kernel team, and dropping the runtime dependeny seems to be the right thing to do at this stage of the game ( especially given the recent scheduler problems ).

A new pulseaudio ( 1:0.9.19-0ubuntu2 ) was just uploaded that drops the rtkit recommends.

Note, you need to manually remove rtkit from your system, as the change doesn't force it to be removed automatically.

Updated Pulseaudio, removed rtkit. No longer rc'v messages re rtkit in syslog. (As expected, its not there lol)

FYI, I added bug #452458 this afternoon re: adding a Conflicts for rtkit, so that it gets removed automatically. That way, we'll get more testing coverage on the configuration that'll be released with Karmic final.

Content from a bug #455978 marked DUP of this.

Primarily for the benefit of security and the usability of Pulse Audio, per Lennart's suggestion, at:

 http://0pointer.de/blog/projects/pa-in-ubuntu.html

and themuso's prior requests to ubuntu-kernel dating from August 2009:

  https://lists.ubuntu.com/archives/kernel-team/2009-August/006941.html

commit and clean-ups:

  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git&a=search&h=HEAD&st=commit&s=SCHED_RESET_ON_FORK

Linux Kernel announcement from May 2009:

  http://lwn.net/Articles/335203/
  "[PATCH] scheduler: introduce SCHED_RESET_ON_FORK scheduling policy flag, Second try"

This doesn't look to me like an appropriate candidate for an SRU kernel update; and in any event, given that we've forcibly removed rtkit from karmic by making pulseaudio conflict with it, there doesn't seem to be much point?

I'd agree. The patches we need for rtkit are in 2.6.32 so we will ahve them for lucid.

+1

I saw Kees update the status the other day too and had meant to ask about it.

I think Tim has made his position clear that the kernel patch isn't going to happen for Karmic ( unless it lands in a standard stable update to the kernel ).

That said, we need to make sure this does happen for Lucid. ;)

Has this landed for Lucid then?

As far as I know, the answer is yes. However my only Lucid system is at home right now, so I can't check.

I'll move this to Incomplete until we have confirmation.

i checked it and it's in lucid's 2.6.32, therefore fix released. but as we won't see a rt patchset for 2.6.32, we should also add the patch to the 2.6.31 based rt kernel for lucid. so far it seems the patch doesn't conflict with patch-2.6.31.6-rt19 and my system is running fine with a patched linux-rt.

BTW as i grabbed it from fedora 12's latest kernel source, i saw there are also some related patches that might be of interest.

This bug was nominated against a series that is no longer supported, ie karmic. The bug task representing the karmic nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.