+++ 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
udev-160-9.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/udev-160-9.fc14
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
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.