Bug 608712 - Switching between text-console and X kills audio
Switching between text-console and X kills audio
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
:
: 595171 (view as bug list)
Depends On:
Blocks: 621975
  Show dependency treegraph
 
Reported: 2010-06-28 10:27 EDT by Thomas Dempton
Modified: 2010-08-19 21:27 EDT (History)
8 users (show)

See Also:
Fixed In Version: udev-153-3.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 621975 (view as bug list)
Environment:
Last Closed: 2010-08-19 21:27:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Thomas Dempton 2010-06-28 10:27:47 EDT
Description of problem:

When I switch between an X session where I have running an audio-player (like xmms with pulseaudio-plugin or amarok) and a text-console where I am logged in as root a few times, my audio playback dies.

It stops when switching to the root text-console (guess this is expected) and usually starts again when I switch back to X.
However sometimes (quite frequently) playback doesn't start when switching back to X.

In this state all audio-apps seem to be hung, restarting e.g. xmms doesn't help at all. I have to re-login to make sound playback work again.


Version-Release number of selected component (if applicable):
Fedora-13 + updates testing (but also happens with stock Fedora 13)

How reproducible:
Happens every time

Steps to Reproduce:
- Start audio player in X
- Log in a text console as root
- Switch between text-console and X a few times
  
Actual results:
After a few switches playback doesn't start again when switching back to X, all audio apps appear to be hung

Expected results:
playback should always start again

Additional info:
I experience this on two different systems, one is equipped with an intel-hda soundcard, the other one has a SiS chip - so I don't think its hardware related.
Comment 1 Michal Schmidt 2010-08-03 04:05:23 EDT
I can reproduce this. The problem is a loss of access (ACL) to the sound devices.
Before the VT switch when everything is fine I have:

$ getfacl /dev/snd/pcmC0D0p
# file: dev/snd/pcmC0D0p
# owner: root
# group: audio
user::rw-
user:michich:rw-      <--- This is good
group::rw-
mask::rw-
other::---

After the bug is reproduced the ACL is gone:

$ getfacl /dev/snd/pcmC0D0p
# file: dev/snd/pcmC0D0p
# owner: root
# group: audio
user::rw-
group::rw-
mask::rw-
other::---

I blame ConsoleKit.
Comment 2 Michal Schmidt 2010-08-03 04:57:04 EDT
After adding a few debug prints I now blame udev.

When switching VT ConsoleKit calls /usr/lib/ConsoleKit/run-seat.d/udev-acl.ck to apply the ACLs. It's a symlink to /lib/udev/udev-acl.

I replaced udev-acl.ck with a shell script which first logs its parameters and environment to syslog and then calls /lib/udev/udev-acl. As far as I can tell, ConsoleKit calls udev-acl with the correct parameters and the bug is in udev-acl itself.

For example, this is a log from three consecutive VT switches:

First a switch from an X session to a text VT where nobody is logged in (only getty running on it):

udev-acl: seat_active_session_changed, env: CK_SEAT_ID=/org/freedesktop/ConsoleKit/Seat1#012CK_SEAT_OLD_SESSION_X11_DISPLAY_DEVICE=/dev/tty1#012CK_SEAT_OLD_SESSION_USER_UID=500#012CK_SEAT_OLD_SESSION_X11_DISPLAY=:0#012CK_SEAT_OLD_SESSION_IS_LOCAL=true#012CK_SEAT_OLD_SESSION_ID=/org/freedesktop/ConsoleKit/Session2

This makes udev-acl correctly remove the ACLs of the user 500.
Second, a switch to another VT, where root is logged in:

udev-acl: seat_active_session_changed, env: CK_SEAT_ID=/org/freedesktop/ConsoleKit/Seat1#012CK_SEAT_SESSION_USER_UID=0#012CK_SEAT_SESSION_DISPLAY_DEVICE=/dev/tty3#012CK_SEAT_SESSION_ID=/org/freedesktop/ConsoleKit/Session3#012CK_SEAT_SESSION_IS_LOCAL=true

udev-acl does not apply any ACLs, because it treats root specially. So far so good, but this special treatment will cause trouble in the next VT switch (back to the user's X session):

udev-acl: seat_active_session_changed, env: CK_SEAT_SESSION_X11_DISPLAY=:0#012CK_SEAT_ID=/org/freedesktop/ConsoleKit/Seat1#012CK_SEAT_SESSION_X11_DISPLAY_DEVICE=/dev/tty1#012CK_SEAT_SESSION_USER_UID=500#012CK_SEAT_OLD_SESSION_DISPLAY_DEVICE=/dev/tty3#012CK_SEAT_SESSION_ID=/org/freedesktop/ConsoleKit/Session2#012CK_SEAT_OLD_SESSION_USER_UID=0#012CK_SEAT_OLD_SESSION_IS_LOCAL=true#012CK_SEAT_SESSION_IS_LOCAL=true#012CK_SEAT_OLD_SESSION_ID=/org/freedesktop/ConsoleKit/Session3

udev-acl understands right that it is being asked for and ACTION_CHANGE by CK, but since root is treated specially, it does not do anything! In the source:

        case ACTION_CHANGE:
                s = getenv("CK_SEAT_OLD_SESSION_USER_UID");
                if (s == NULL)
                        return -1;
                u = strtoul(s, NULL, 10);
                if (u == 0)
                        return 0;

See? It stops processing the request. This is wrong. udev-acl may want to prevent removing ACLs from root, but it must not stop the ACLs being granted to the user of the new session.
Comment 3 Michal Schmidt 2010-08-04 06:03:48 EDT
I see Kay attempted to fix it:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=939cc18afc49ee8479572c14c7fa777646fd4add
but the fix is incomplete. I posted an additional patch:
http://www.spinics.net/lists/hotplug/msg04050.html
which works in my testing.
Comment 4 Michal Schmidt 2010-08-04 06:48:36 EDT
*** Bug 595171 has been marked as a duplicate of this bug. ***
Comment 5 Marcela Mašláňová 2010-08-04 07:51:32 EDT
(In reply to comment #3)
> I see Kay attempted to fix it:
> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=939cc18afc49ee8479572c14c7fa777646fd4add
> but the fix is incomplete. I posted an additional patch:
> http://www.spinics.net/lists/hotplug/msg04050.html
> which works in my testing.    

Thanks Michal. Your patch works for me (KDE, amarok, F-13).
Comment 6 Fedora Update System 2010-08-05 02:49:46 EDT
udev-153-2.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/udev-153-2.fc13
Comment 7 Fedora Update System 2010-08-05 19:48:53 EDT
udev-153-2.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update udev'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/udev-153-2.fc13
Comment 8 Fedora Update System 2010-08-13 04:39:34 EDT
udev-153-3.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/udev-153-3.fc13
Comment 9 Fedora Update System 2010-08-19 21:27:13 EDT
udev-153-3.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.