Bug 621975

Summary: Switching between text-console and X kills audio
Product: [Fedora] Fedora Reporter: Harald Hoyer <harald>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: harald, jmccann, jonathan, jreznik, linuxhippy, lkundrak, lpoetter, mschmidt, t.dempton
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: udev-160-9.fc14 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 608712 Environment:
Last Closed: 2010-08-11 00:20:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 608712    
Bug Blocks:    

Description Harald Hoyer 2010-08-06 16:46:12 UTC
+++ This bug was initially created as a clone of Bug #608712 +++

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.

--- Additional comment from mschmidt on 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.

--- Additional comment from mschmidt on 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.

--- Additional comment from mschmidt on 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.

--- Additional comment from mschmidt on 2010-08-04 06:48:36 EDT ---

*** Bug 595171 has been marked as a duplicate of this bug. ***

--- Additional comment from mmaslano on 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).

--- Additional comment from updates on 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

--- Additional comment from updates on 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 1 Fedora Update System 2010-08-06 16:49:51 UTC
udev-160-9.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/udev-160-9.fc14

Comment 2 Fedora Update System 2010-08-10 01:31:51 UTC
udev-160-9.fc14 has been pushed to the Fedora 14 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-160-9.fc14

Comment 3 Fedora Update System 2010-08-11 00:20:18 UTC
udev-160-9.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.