Bug 99356 - pulseaudio hangs when rtkit cannot start
Summary: pulseaudio hangs when rtkit cannot start
Alias: None
Product: PulseAudio
Classification: Unclassified
Component: daemon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: pulseaudio-bugs
QA Contact: pulseaudio-bugs
Depends on:
Reported: 2017-01-11 08:06 UTC by BogDan Vatra
Modified: 2018-07-30 10:28 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Description BogDan Vatra 2017-01-11 08:06:44 UTC
Pulseaudio ~hangs (actually it waits 25s for every call) in rtkit_make_high_priority, when it calls dbus_connection_send_with_reply_and_block .... it happens because rtkit fails to start :(

I report this bug first here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850806
Comment 1 BogDan Vatra 2017-01-11 08:10:31 UTC
Ther rtkit problem is traced here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850855
Comment 2 Tanu Kaskinen 2017-01-20 09:42:52 UTC
I added Felipe to CC, because this is directed more to him: in the Debian bug you said that "pulseaudio should not hang when rtkit cannot start". I'm not sure I agree. If pulseaudio hangs, I believe it means that D-Bus thinks that rtkit is available, but starting it takes a long time for some strange reason. If rtkit is simply not installed, I think D-Bus will error out immediately. It seems reasonable to assume that if rtkit is installed, it can be started.

I think it's fine if someone writes a patch to make pulseaudio handle weird rtkit problems better, but I don't think this is strictly speaking a pulseaudio bug.
Comment 3 Felipe Sateler 2017-01-20 12:37:42 UTC
I think I have traced the problem.

Rtkit fails to start because PrivateTmp= conflicts with symlinks in /var. This is a bug in systemd (but I have not filed it yet).

DBus apparently never stops trying to start it, until the timeout is reached (by default 25 seconds). Thus, one would expect to have pulseaudio have a delayed start of 25 seconds. Not so, because pa_raise_priority:

    if (set_nice(nice_level) >= 0) {
        pa_log_info("Successfully gained nice level %i.", nice_level);
        return 0;

    for (n = nice_level+1; n < 0; n++)
        if (set_nice(n) >= 0) {
            pa_log_info("Successfully acquired nice level %i, which is lower than the requested %i.", n, nice_level);
            return 0;

If set_nice fails, pulseaudio will try successively higher nice levels until it reaches 0 (probably assuming it was started with 0 niceness). nice_level is by default -11, so there would be 11 calls to set_nice => 11*25 = 4:35 minutes.

BogDan Vatra, if you wait more than 5 minutes, does pulseaudio eventually start? If this hypothesis is confirmed, then the solution would be to either:

1. Lower the timeout
2. detect that rtkit did not work the first time because dbus could not start rtkit, and do not try to contact it again in successive retries.
Comment 4 BogDan Vatra 2017-01-20 13:22:20 UTC
@Felipe Sateler: yes, it starts.
Comment 5 BogDan Vatra 2017-01-20 13:36:01 UTC
IMHO set_nice should return a different ERROR code if it can't connect to rtkit. Tih way you can skip the "for (n = nice_level+1; n < 0; n++)"
Comment 6 GitLab Migration User 2018-07-30 10:28:06 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/441.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.