Bug 99356

Ther rtkit problem is traced here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850855

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.

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.

@Felipe Sateler: yes, it starts.

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++)"

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