Dear Maintainer,

   * What led up to the situation?

open rdesktop
close rdesktop by clicking on x in corner
open program using sound
close program

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

Attempted to run program that uses sound after a program that isn't well behaved.

   * What was the outcome of this action?

Sound did not play. Program hung up on close.

   * What outcome did you expect instead?

pulseaudio cleans up after program using it drops out from under it.
Regression from wheezy. Regression from February 2015.

Could you please attach a verbose log[1] of pulseaudio when this happens?

Also, please try the version in experimental to see if it fixes this issue.


[1]https://wiki.ubuntu.com/PulseAudio/Log

Saludos,
Felipe Sateler

PS: please keep the bug on cc.

Ok got the bug repro nailed down. rdesktop wasn't the actual culpret:
Ctrl-Alt-F2 followed by followed by Ctrl-Alt-F7 was. (There would
normally be a VPN setup step in between but it's not necessary to
repro).

So I started firefox, opened up CNN.com, started playing any movie,
pressed Ctrl-Alt-F2, ran ls on terminal, pressed Ctrl-Alt-F7, and then
sound failed. Firefox jammed when closing the CNN.com tab requiring
closing the browser. Tried defcon (game), found no sound was present,
and the game hung on closing (there is a demo of defcon if you need it
for further repro) but I don't think you do as the "no sound" part can
be reproduced with most sound using programs.

The repro seems to be statistical but with a very chance for me of
hitting it (>> 0.5).

joshua@nova:~ϟ pulseaudio --version
pulseaudio 5.0

Does audio continue working while you are on tty2? Is tty2 logged in?

The log seems to have some corrupt lines, could you try generating a
new one? Also, please mark the time when the error occurs so I can
trace it on the log.

Yes and irrelevant (happens either way) Note that tty2 is a TEXT console (no X).

I did a reproduction with echo "--MARK--" >> ~/pulseverbose.log and
killed pulseaudio immediately after (within 5 seconds) by ^C. However
the echo line does not appear anywhere in the log file. Tried twice.
No good. Maybe the 5 second window is good enough.

Killing pulseaudio results in a sane system but sound will not play
until a graphics logoff/logon. Curious.

s/Killing pulseaudio/Killing and restarting pulseaudio/

Hi,

I'm not sure it is irrelevant:

% grep accessible pulseverbose.log
(   0.011|   0.001) D: [pulseaudio] module-udev-detect.c:
/dev/snd/controlC0 is accessible: yes
(   0.057|   0.000) D: [pulseaudio] module-udev-detect.c:
/dev/snd/controlC1 is accessible: yes
(   0.116|   0.000) D: [pulseaudio] module-udev-detect.c:
/dev/snd/controlC0 is accessible: yes
(   0.116|   0.000) D: [pulseaudio] module-udev-detect.c:
/dev/snd/controlC1 is accessible: yes
(   5.121|   0.000) D: [pulseaudio] module-udev-detect.c:
/dev/snd/controlC0 is accessible: yes
(   5.121|   0.000) D: [pulseaudio] module-udev-detect.c:
/dev/snd/controlC1 is accessible: yes
(  13.798|   2.826) D: [pulseaudio] module-udev-detect.c:
/dev/snd/controlC0 is accessible: yes
(  13.798|   0.000) D: [pulseaudio] module-udev-detect.c:
/dev/snd/controlC1 is accessible: yes
(  13.820|   0.022) D: [pulseaudio] module-udev-detect.c:
/dev/snd/controlC0 is accessible: yes
(  13.820|   0.000) D: [pulseaudio] module-udev-detect.c:
/dev/snd/controlC1 is accessible: yes
(  22.031|   8.210) D: [pulseaudio] module-udev-detect.c:
/dev/snd/controlC0 is accessible: yes
(  22.031|   0.000) D: [pulseaudio] module-udev-detect.c:
/dev/snd/controlC1 is accessible: yes
(  22.032|   0.001) D: [pulseaudio] module-udev-detect.c:
/dev/snd/controlC0 is accessible: no
(  22.032|   0.000) D: [pulseaudio] module-udev-detect.c:
/dev/snd/controlC1 is accessible: no
(  22.032|   0.000) D: [pulseaudio] module-udev-detect.c:
/dev/snd/controlC1 is accessible: no

So in the beginning the cards are accessible, but somewhere along the
line they become inaccessible.

When you lose sound, what does `pactl list sinks` say?

Init: sysvinit (via /sbin/init)

Could you try booting under systemd and see if this problem persists?
Maybe the bug is in the systemd-shim layer. Pulseaudio relies on
logind or consolekit to correctly set the ACLs on the audio devices.

Hmmm. systemd-logind is running. Maybe we got a genuine systemd bug
that I tried to avoid by not upgrading init. If I just pin the ACLs at
666 (this is safe on a single-user box) and the problem goes away
would that confirm where to look?

I miss the old "console" group. A much simpler solution.

Indeed. chmod 666 /dev/snd/* makes the problem go away.

Control: reassign -1 systemd-shim
Control: retitle -1 access to /dev/snd/* lost after switch to tty2 and back

But this is a different implementation as the original requires
systemd as init daemon, this one is modified to not need it.

I am reassigning to systemd-shim. Hopefully the maintainers will know
where to look further.

For this particular case you can use the audio group.

On further diagnostic (now that we know for sure what we are looking
for), the user logged in to TTY2 is relevant. This eliminates the
statistical match for a hard match to the problem. If the TTY is
logged in as root or not logged in, happens every time.

I'm in the habit of doing all root work directly from text consoles
(no X as root for the obvious reason). This is actually more secure
than sudo as an X key sniffer can never grab the root password. A
program that requires X doesn't get root. I make no exceptions except
xterm (testing X config files).

I think this is still a direct bug. Users able to play sound ought to
be the sum of all logged-in users on all TTY sessions (X or text), not
just the current one.

I'm adding my user to audio group for now.

switch to TTY2 and your user is not logged in. This is fully expected.
The second is that when you return to X your sound does not return.
This is the bug that needs debugging.

But this would mean that either any user can eavesdrop on other user's
audio, or a currently-seating user does not have access to the sound
device (because the other user is using it).

This is only really appropriate for single-user computers.

This is the bug that needs debugging.

Output of getfacl suggests permissions are being restored correctly
but pulseaudio is getting stuck by the transient. Given the
statistical nature of the inital repro with same user on TTY2, I
suggest the transient is there even when switching between two
same-users sessions but is often too fast for pulseaudio to get stuck.

joshua@nova:~ϟ getfacl /dev/snd/*
# file: dev/snd/by-path
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

# file: dev/snd/controlC0
# owner: root
# group: audio
user::rw-
user:joshua:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/controlC1
# owner: root
# group: audio
user::rw-
user:joshua:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/hwC0D0
# owner: root
# group: audio
user::rw-
user:joshua:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/hwC1D0
# owner: root
# group: audio
user::rw-
user:joshua:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC0D3p
# owner: root
# group: audio
user::rw-
user:joshua:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC1D0c
# owner: root
# group: audio
user::rw-
user:joshua:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC1D0p
# owner: root
# group: audio
user::rw-
user:joshua:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC1D1p
# owner: root
# group: audio
user::rw-
user:joshua:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC1D2c
# owner: root
# group: audio
user::rw-
user:joshua:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/seq
# owner: root
# group: audio
user::rw-
user:joshua:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/timer
# owner: root
# group: audio
user::rw-
user:joshua:rw-
group::rw-
mask::rw-
other::---

Control: reassign -1 pulseaudio

Reassigning back to pulseaudio then, as it no longer looks like a
problem in logind.

Does pulseaudio get unstuck by doing another roundtrip to tty2?

And please try to see if this problem is still present in pulseaudio 6.

Nope. I haven't found an unstick short of X logoff-logon. Killing
pulseaudio does not unstick.

Will try pull from experimental soon.