When pulseaudio first starts up, I find these lines with maximally verbose logging: pulseaudio[4286]: [pulseaudio] module-udev-detect.c: Found 0 cards. pulseaudio[4286]: [pulseaudio] module.c: Loaded "module-udev-detect" (index: #4; argument: ""). It then adds a "Dummy output" sink, and pactl -l only shows the dummy (null) output. fuser shows nothing using the card, and if I kill pulseaudio and restart it, the same problem occurs, so it doesn't seem to relate to a program using the card at boot. I had this problem with the stable versions of pulseaudio and udev (pulseaudio 1.1 and udev 171-r8), so I updated to testing (pulseaudio 2.1-r1 and udev 195), but there was no change. However, I did find this post on the Italian forums that mentioned a similar issue being solved with udevadm trigger: http://forums.gentoo.org/viewtopic-t-918580-start-0.html This also works for me. Unfortunately, I don't know udev well enough to understand what this means. Another (English) forum post that may be the same thing: http://forums.gentoo.org/viewtopic-t-918670-start-0.html Actually, to be clear, I have two sound outputs (the sound card and the HDMI audio output of my video card). The above applies to both of them. Reproducible: Always Steps to Reproduce: 1. Reboot, or "killall pulseaudio" and allow it to respawn. 2. "sudo udevadm trigger" Actual Results: Card is not discovered by pulseaudio until "udevadm trigger" is run. Expected Results: Pulseaudio's udev-detect module should see the sound card when it is first loaded. I've been experimenting with the hardened kernel a bit on my desktop, but grsec.log does not show any issue with pulseaudio, except that it objects to pulseaudio re-nicing itself to -11 and stops logging due to too many messages (and/or it does the same thing to pulseaudio requesting realtime priority if that option is turned on). If I fix this, it turns out that there's nothing else in the log that would explain this.
Created attachment 327648 [details] emerge --info pulseaudio udev udev-init-scripts
This sounds like a grsec issue - works just fine on all the systems I have ever seen. CC'ing hardened to see if they know what might be happening.
I agree; my initial suspicion was that some grsecurity filesystem options might have been the problem; I was trying to figure out what precisely the issue was without having to disable them one-by-one (which, in retrospect, probably would have been the fastest way to figure this out). What confused me is that the udevadm trigger mechanism works at all (although now it makes more sense to me, since running that command as root re-provides information that probably isn't available when pulseaudio starts). Anyway, I just now tried the obvious experiment, and started pulseaudio as root with -vvvv. Now pulseaudio detects the card (while running as a normal user with pulseaudio suid as root does not work). So that narrows it down.
This is caused by CONFIG_GRKERNSEC_SYSFS_RESTRICT (which I feel a bit dumb for not figuring out before). Since non-root can't get at /sys, root needs to run "udevadm trigger --subsystem-match=sound" (or something like it) in order to re-run the appropriate events. I'm not sure what to think here; maybe this bug should be INVALID? There are a number of possible, but not ideal, workarounds (dump pulseaudio and use bare ALSA, use system-wide pulseaudio, turn off SYSFS_RESTRICT, use udevadm to trigger the card every time pulseaudio restarts, probably other things I can't think of right now). I guess one question is whether SYSFS_RESTRICT is intended to work with a typical desktop environment, or if it was my mistake for turning it on in the first place. AFAICT, pulseaudio is the only program affected on my system.
+1 for INVALID due to wrong user settings of kernel
This seems to hit people every few months, and I always forget what the culprit was, so I've blogged about it at: http://arunraghavan.net/2012/10/grsec-and-pulseaudio/ Marking INVALID now.
