Description of problem: As quick as X server is started, alsa is not accessible. So, application can not access to alsa. Pulseaudio start, but do not work. As quick as X is finished, alsa is accessible for applications again... Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.6.0-9.fc11.i586 alsa-tools-1.0.19-3.fc11.i586 alsa-plugins-pulseaudio-1.0.18-3.fc11.i586 alsa-utils-1.0.19-4.fc11.i586 alsa-lib-1.0.19-3.fc11.i586 kernel-2.6.29-0.218.rc7.git2.fc11.i586 How reproducible: 100% Steps to Reproduce: 1. boot rawhide in runlevel 3 2. Login from remote PC by ssh 2. check is alsa accessible `alsamixer -c 0` in ssh session (accessible) 3. start 'X' by `startx` or directly by `/usr/bin/X` as user in rawhide console 4. check is alsa accessible `alsamixer -c 0` in ssh session (is not) 5. stop 'X' Actual results: 1. pulseaudio can not start correct: tail /var/log/messages Mar 12 21:43:56 rawhide pulseaudio[2741]: module-alsa-card.c: Card '0' doesn't exist... 2. alsamixer can not access to hw: [sergeil@rawhide ~]$ alsamixer -c 0 wrong -c argument '0' Expected results: pulseaudio start and work alsamixer or any other application start and work correct with alsa. Additional info: 1. System is fully updated till right now. 2. I has tested it as user, root, with selinux enabled, with selinux disabled. It is the same... 3. Environment: KVM qemu-kvm -localtime -std-vga -hda rawhide.img -boot c -net nic,macaddr=52:54:00:12:34:FB,model=virtio -net tap -soundhw es1370 -m 1024 KVM version: etherboot-roms-kvm-5.4.4-5.fc10.i386 kvm-74-10.fc10.i386
Aftef update: 1. root can use alsa even X is started. 2. user can use alsa if it is permitted read/write /dev/snd/* 3. after X is finished, user can use alsa, even if attributes of /dev/snd/* are standard [root@rawhide snd]# ll /dev/snd итого 0 crw-rw----+ 1 root audio 116, 8 Мар 15 13:32 controlC0 crw-rw----+ 1 root audio 116, 4 Мар 15 13:32 midiC0D0 crw-rw----+ 1 root audio 116, 7 Мар 15 13:52 pcmC0D0c crw-rw----+ 1 root audio 116, 6 Мар 15 15:47 pcmC0D0p crw-rw----+ 1 root audio 116, 5 Мар 15 13:32 pcmC0D1p crw-rw----+ 1 root audio 116, 3 Мар 15 13:32 seq crw-rw----+ 1 root audio 116, 2 Мар 15 13:32 timer
Some add. After login in text console (not by SSH), user sergeil is permitted to use alsa and getfact show right permissions for alsa devices. [sergeil@rawhide ~]$ getfacl /dev/snd/* -------- getfacl: Removing leading '/' from absolute path names # file: dev/snd/controlC0 # owner: root # group: audio user::rw- user:sergeil:rw- group::rw- mask::rw- other::--- # file: dev/snd/midiC0D0 # owner: root # group: audio user::rw- user:sergeil:rw- group::rw- mask::rw- other::--- # file: dev/snd/pcmC0D0c # owner: root # group: audio user::rw- user:sergeil:rw- group::rw- mask::rw- other::--- # file: dev/snd/pcmC0D0p # owner: root # group: audio user::rw- user:sergeil:rw- group::rw- mask::rw- other::--- # file: dev/snd/pcmC0D1p # owner: root # group: audio user::rw- user:sergeil:rw- group::rw- mask::rw- other::--- # file: dev/snd/seq # owner: root # group: audio user::rw- user:sergeil:rw- group::rw- mask::rw- other::--- # file: dev/snd/timer # owner: root # group: audio user::rw- user:sergeil:rw- group::rw- mask::rw- other::--- --------------- But, as soon, as X server is started, user lose permissions to use alsa devices. [sergeil@rawhide ~]$ getfacl /dev/snd/* getfacl: Removing leading '/' from absolute path names # file: dev/snd/controlC0 # owner: root # group: audio user::rw- group::rw- mask::rw- other::--- # file: dev/snd/midiC0D0 # owner: root # group: audio user::rw- group::rw- mask::rw- other::--- # file: dev/snd/pcmC0D0c # owner: root # group: audio user::rw- group::rw- mask::rw- other::--- # file: dev/snd/pcmC0D0p # owner: root # group: audio user::rw- group::rw- mask::rw- other::--- # file: dev/snd/pcmC0D1p # owner: root # group: audio user::rw- group::rw- mask::rw- other::--- # file: dev/snd/seq # owner: root # group: audio user::rw- group::rw- mask::rw- other::--- # file: dev/snd/timer # owner: root # group: audio user::rw- group::rw- mask::rw- other::--- So, X server restore standard ACL for alsa, but do not setup it again for user. After X server is finished (not killed), user have access to alsa again [sergeil@rawhide ~]$ getfacl /dev/snd/* getfacl: Removing leading '/' from absolute path names # file: dev/snd/controlC0 # owner: root # group: audio user::rw- user:sergeil:rw- group::rw- mask::rw- other::--- # file: dev/snd/midiC0D0 # owner: root # group: audio user::rw- user:sergeil:rw- group::rw- mask::rw- other::--- # file: dev/snd/pcmC0D0c # owner: root # group: audio user::rw- user:sergeil:rw- group::rw- mask::rw- other::--- # file: dev/snd/pcmC0D0p # owner: root # group: audio user::rw- user:sergeil:rw- group::rw- mask::rw- other::--- # file: dev/snd/pcmC0D1p # owner: root # group: audio user::rw- user:sergeil:rw- group::rw- mask::rw- other::--- # file: dev/snd/seq # owner: root # group: audio user::rw- user:sergeil:rw- group::rw- mask::rw- other::--- # file: dev/snd/timer # owner: root # group: audio user::rw- user:sergeil:rw- group::rw- mask::rw- other::---
Problem can be solved by restoring fragment (assign CK_XINIT_SESSION) from F10. PS: Variable XDG_SESSION_COOKIE is already defined here. [sergeil@rawhide ~]$ diff -urN /etc/X11/xinit/xinitrc-common.org /etc/X11/xinit/xinitrc-common --- /etc/X11/xinit/xinitrc-common.org 2009-03-21 15:51:42.000000000 +0200 +++ /etc/X11/xinit/xinitrc-common 2009-03-21 15:58:26.000000000 +0200 @@ -64,7 +64,10 @@ fi fi +#CK_XINIT_SESSION= +#if [ -x /usr/bin/ck-xinit-session -a -z "$XDG_SESSION_COOKIE" ]; then +# CK_XINIT_SESSION="/usr/bin/ck-xinit-session" +#fi + CK_XINIT_SESSION= -if [ -x /usr/bin/ck-xinit-session -a -z "$XDG_SESSION_COOKIE" ]; then - CK_XINIT_SESSION="/usr/bin/ck-xinit-session" -fi +[ -x /usr/bin/ck-xinit-session ] && CK_XINIT_SESSION="/usr/bin/ck-xinit-session"
Variable XDG_SESSION_COOKIE is known in text console (after user logon). So, if user start X system from console (by running startx), CK_XINIT_SESSION will be unknown and user lose access, as minimum, to sound. PS: IMHO, startx have to undefine variable XDG_SESSION_COOKIE or make some other preparation.
Resolving of problem is simple: to add "unset XDG_SESSION_COOKIE" in /usr/bin/startx after "unset SESSION_MANAGER" [root@rawhide ~]# more /usr/bin/startx ... unset DBUS_SESSION_BUS_ADDRESS unset SESSION_MANAGER unset XDG_SESSION_COOKIE ...
Fixed in xinit 1.0.9-7.fc11, thanks!