rtkit requires a kernel patch

Bug #406702 reported by Johan Kiviniemi on 2009-07-30
This bug affects 32 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Luke Yelavich
Nominated for Lucid by bojo42
Luke Yelavich
linux-rt (Ubuntu)
Nominated for Lucid by bojo42

Bug Description

TheMuso said a kernel patch will fix this. The original bug report about rtkit follows.

Upon starting, rtkit warns:

rtkit-daemon[13198]: Failed to make ourselves RT: Invalid argument


13198 clone(child_stack=0xb76a64b4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb76a6bd8, {entry_number:6, base_addr:0xb76a6b90, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb76a6bd8) = 13200
13200 set_robust_list(0xb76a6be0, 0xc) = 0
13200 rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], NULL, 8) = 0
13200 sched_setscheduler(0, 0x40000002 /* SCHED_??? */, { 99 }) = -1 EINVAL (Invalid argument)
13200 time(NULL) = 1248922438
13200 writev(2, [{"rtkit-daemon[13198]: Failed to make ourselves RT: Invalid argument\n", 67}], 1) = 67

rtkit: 0.3-0ubuntu2

linux-image-2.6.31-4-generic-pae: 2.6.31-4.23
Linux hapatus 2.6.31-4-generic-pae #23-Ubuntu SMP Mon Jul 27 19:37:25 UTC 2009 i686 GNU/Linux

Johan Kiviniemi (ion) on 2009-07-30
description: updated
summary: - Failed to make ourselves RT: Invalid argument
+ rtkit requires a kernel patch
affects: rtkit (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
assignee: nobody → Luke Yelavich (themuso)

Architecture: i386
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: rtkit 0.4-0ubuntu2
PackageArchitecture: i386
 PATH=(custom, user)
ProcVersionSignature: Ubuntu 2.6.31-7.27-generic
Uname: Linux 2.6.31-7-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

dino99 (9d9) wrote :
tags: added: apport-collected
dino99 (9d9) wrote :

Same warning here

Luís Louro (lapisdecor) wrote :


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

Anand Kumria (wildfire) wrote :

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).

Tony Espy (awe) wrote :

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.

Tony Espy (awe) wrote :

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 ).

Changed in linux (Ubuntu):
status: New → Confirmed

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.

Tony Espy (awe) wrote :

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.

Luke Yelavich (themuso) wrote :

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

Tony Espy (awe) wrote :

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 ).

Tony Espy (awe) wrote :

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.

Kzin (wmkzin) wrote :

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

Tony Espy (awe) wrote :

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.

Tony Espy (awe) wrote :

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:


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


commit and clean-ups:


Linux Kernel announcement from May 2009:

  "[PATCH] scheduler: introduce SCHED_RESET_ON_FORK scheduling policy flag, Second try"

Kees Cook (kees) on 2009-10-29
Changed in linux (Ubuntu Karmic):
assignee: nobody → Luke Yelavich (themuso)
milestone: none → karmic-updates
status: New → Confirmed
Steve Langasek (vorlon) wrote :

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?

Luke Yelavich (themuso) wrote :

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

Tony Espy (awe) wrote :


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. ;)

Anand Kumria (wildfire) wrote :

Has this landed for Lucid then?

Tony Espy (awe) wrote :

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.

Tony Espy (awe) on 2010-01-29
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Changed in linux (Ubuntu Karmic):
status: Confirmed → Incomplete
bojo42 (bojo42) on 2010-01-31
Changed in linux-rt (Ubuntu):
status: New → Confirmed
Changed in linux (Ubuntu):
status: Incomplete → Fix Released
bojo42 (bojo42) wrote :

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- 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.

Changed in linux-rt (Ubuntu):
assignee: nobody → Luke Yelavich (themuso)
Changed in linux-rt (Ubuntu):
assignee: Luke Yelavich (themuso) → nobody

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.

Changed in linux (Ubuntu Karmic):
status: Incomplete → Won't Fix
dino99 (9d9) on 2012-01-17
Changed in linux-rt (Ubuntu Karmic):
status: New → Incomplete
Changed in linux-rt (Ubuntu):
status: Confirmed → Incomplete
Changed in linux-rt (Ubuntu Karmic):
status: Incomplete → New
Changed in linux-rt (Ubuntu):
status: Incomplete → Confirmed
dino99 (9d9) on 2013-04-26
Changed in linux-rt (Ubuntu Karmic):
status: New → Invalid
Changed in linux-rt (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers