Created attachment 441198 [details] Output of "emerge --info pulseaudio" pulseaudio-8.0 and 9.0 both refuse all audio connections on my system. Example: playing a sound file in mpv with ao-pulse defined returns "[ao/pulse] Init failed: Connection refused" Doing the same through ALSA (Setting "pcm.default pulse" and "ctl.default pulse" in asound.conf) returns "ALSA lib /var/tmp/portage/media-plugins/alsa-plugins-1.1.1/work/alsa-plugins-1.1.1/pulse/pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused "[ao/alsa] Playback open error: Connection refused" and attempts to use another device. When pavucontrol is run while the daemon is running, the message "Establishing connection with pulseaudio, please wait..." message appears in a blank window and hangs there, unable to connect. Additionally, any attempt to use pulseaudio -k to stop the daemon once running will return "Failed to kill daemon; no such process"--meaning that the daemon seemingly isn't finding its own PID? Quite odd. Meanwhile, direct ALSA output works perfectly on my system. =\ My desktop environment is Plasma 5. All config files in /etc/pulse are pristine defaults. The output of 'emerge --info pulseaudio' is attached below, followed by a log of "pulseaudio -vvvvv" output on startup, roughly 15 seconds of idle state, then termination. Examining the log yields no clear solution for me as I'm unfamiliar with how pulseaudio scans devices and modules... Further data (obviously) available on request.
Created attachment 441200 [details] Log of 15 seconds of pulseaudio startup, idle state and termination
Additional notes: - The PULSE_SERVER environment variable does not become set while pulseaudio is running. - Running "pax11publish -d" returns nothing. - "pulseaudio -check -vvvvv" returns "I: [pulseaudio] main.c: Daemon not running", which is consistent with pulseaudio not finding its own PID. Oh, and my init system is OpenRC+consolekit.
Maybe you will need to temporally prevent daemon from reloading to allow you to get something useful with pulseaudio -vvv: https://fedoraproject.org/wiki/How_to_debug_PulseAudio_problems#General_advice
Added "; autospawn = no" in client.conf. So far I don't seem to have found anything useful, but I'll attach the new log here. (Good to see you again, Mr. Ramos. ^^)
Created attachment 442026 [details] Log of 15 seconds of pulseaudio startup, idle state and termination (with "autospawn = no" in client.conf)
Added "autospawn = no" in client.conf. So far I don't seem to have found anything useful, but I'll attach the new log here. (Good to see you again, Mr. Ramos. ^^)
(Err, sorry for spam. Thought I could delete the previous comment)
I see errors like: D: [pulseaudio] reserve-wrap.c: Successfully acquired reservation lock on device 'Audio1' I: [pulseaudio] (alsa-lib)utils.c: could not open configuration file /usr/share/alsa/ucm/HDA NVidia/HDA NVidia.conf I: [pulseaudio] (alsa-lib)parser.c: error: could not parse configuration for card HDA NVidia I: [pulseaudio] (alsa-lib)main.c: error: failed to import HDA NVidia use case configuration -2 I: [pulseaudio] alsa-ucm.c: UCM not available for card HDA NVidia [...] (and then many more) What kernel are you running? It looks like a misconfigured kernel, sometimes, you have the hda module built, but the needed codecs are missing... I would then double check the kernel config Other option would be to try with an older kernel that was working before with you
the snd-intel8x0 driver is built. As far as I've seen, my kernel contains no further codecs for nvidia; I checked everywhere else, including under HD-Audio where you'd think the missing codecs would be. =\ So I'm really at a loss, there--
Additional information for Mr. Ramos: I run kernel 4.4.6. Attaching .config in case I somehow missed something.
Created attachment 442140 [details] .config (linux-4.4.6-gentoo)
Just managed to confirm an additional symptom likely related to this bug: Whenever the audio device is opened by an application, a directory is created named "(null)" in the cwd directory (where the application that opened the device was run). This directory contains a subdirectory named "pulse". Both directories are completely devoid of files and remain even when an application exits. I did some checking with lsof and the tested applications I run do indeed load in libpulseaudio, even though they don't do anything with it (nor do they do anything with the (null) directory). Mr. Ramos, does this help any?
Do you have HOME and XDG_RUNTIME_DIR set in your environment and what are their values?(In reply to Megas of Vecanti from comment #1) > Created attachment 441200 [details] > Log of 15 seconds of pulseaudio startup, idle state and termination > W: [pulseaudio] main.c: This program is not intended to be run as root (unless --system is specified). Why you run it under root credentials? o_O
>Do you have HOME and XDG_RUNTIME_DIR set in your environment and what are their values? HOME=/root XDG_RUNTIME_DIR=/var/run/user/0 >Why you run it under root credentials? o_O Confidential reasons.
And, does it work on a "normal" user?
The following error is returned: "E: [pulseaudio] core-util.c: XDG_RUNTIME_DIR (/var/run/user/0) is not owned by us (uid 1000), but by uid 0! (This could e g happen if you try to connect to a non-root PulseAudio as a root user, over the native protocol. Don't do that.)" (Note that pulseaudio wasn't running at the time.) Changing /var/run/user's owner/group from root:root to [name of user]:users returned: "E: [pulseaudio] core-util.c: Failed to create secure directory (/var/run/user/0/pulse): Permission denied" -vvv in both cases turned up nothing. The directory's permissions were 700.
Why XDG_RUNTIME_DIR in your normal user's environment is "/var/run/user/0" and not "/var/run/user/1000"? Same goes for HOME.
HOME is the proper directory, but XDG_RUNTIME_DIR is indeed 0 and not 1000. Apparently the 1000 directory wasn't even created. Quite odd. I'm not sure what's going on here. There aren't any clues I can find in the two xdg-related files in /etc/env.d either. The non-root user just _uses_ 0 without any variance--
Do you have something setting XDG_RUNTIME_DIR is bashrc, bash_profile...? Also, in systemd this is handled by pam-systemd... but I don't know what is taking care of setting it in consolekit+openrc :/ Consolekit2 is supposed to do that https://github.com/ConsoleKit2/ConsoleKit2/commit/93d957b7dbe9841dd50bacb18cd36f5e737d81fb
The non-root user has a default .bashrc and .bash_profile. Nothing in either of them sets XDG_RUNTIME_DIR. Furthermore, /etc/bash and /etc/profile.d don't contain anything that set the variable in question. /etc/profile.env is compiled to set: export XDG_CONFIG_DIRS='/etc/xdg' export XDG_DATA_DIRS='/usr/local/share:/usr/share' ...And there are some entries in env.d that set XDG config directory locations, but that's all. In fact, /etc/ only contains a single file that includes the text of "XDG_RUNTIME_DIR" and that's in a comment. I have consolekit-1-1.0-r1 installed currently. If 2.0 has the needed hooks for managing it, do you think I should bite the bullet and unmask -9999? Or is there a way to force a manually-created directory to be seen?
So tonight I found out that switching users merely via su inherits all of the user's variables. _this_ explains why the user was read as 0. My bad, I'm sorry, I have that figured out now. My profile setup is not at fault and XDG definitions are as they should. Now! After running an X session from a base VT as the non-root user _yes,_ pulseaudio runs. pavucontrol sees channels, though I had to mess with the settings a little to get it to play ball, but it runs cleanly without any issues. I made a -vvv log of 15 seconds of idle activity as the non-root user, for comparison. Attaching below.
Created attachment 442666 [details] Log of 15 seconds of pulseaudio startup, idle state and termination (as non-root user)
This is invalid then For the future: *always* use "su -" and not "su" alone
Wait, wait, why resolve it?! It still fails to work as root user, even with the --system switch (which is the intended way to run pulseaudio as root--and even then it's supposed to be called and run automatically either way, which it isn't!). This still proves a severe issue for my use case.
Agh, sorry for the double post. Mouse slipped on the button =\
Then you should put more details about your setup and what you are trying to get. If you become a root vis su/sudo, then make sure that DISPLAY variable is preserved. (In reply to Megas of Vecanti from comment #25) > Wait, wait, why resolve it?! It still fails to work as root user, even with > the --system switch (which is the intended way to run pulseaudio as > root--and even then it's supposed to be called and run automatically either > way, which it isn't!). Note entirely correct. "--system" switch is the way to run system-wide pulseaudio instance. And you need special user and groups because pulseaudio drops its privileges in that mode.
(In reply to Alexander Tsoy from comment #27) > If you become a root vis su/sudo, then make sure that DISPLAY variable > is preserved. And XAUTHORITY of couse
I'm trying to get pulseaudio to _not_ refuse connections and exhibit the listed behavior. I haven't become root via su this entire time--my issue was becoming a _non-root user_ for the sake of testing and I resolved that. It turns out that pulseaudio runs cleanly as a non-root user, but _not_ as a root user where instead the behavior listed in the bug becomes evident and it refuses all incoming connections. All testing has otherwise been done on an X server on top of a clean root login. DISPLAY and XAUTHORITY are the correct values and X server access is granted in these circumstances. All testing I've made for the sake of resolving this bug has been done in this environment (outside of the non-root user mess-up which, as stated above, was corrected). Now...Taking all of the data provided above in that context, what other data do you want me to provide about my system? What else would help you diagnose this issue? I can offer as much as I possibly can.
(In reply to Megas of Vecanti from comment #25) > Wait, wait, why resolve it?! It still fails to work as root user, even with > the --system switch (which is the intended way to run pulseaudio as > root--and even then it's supposed to be called and run automatically either > way, which it isn't!). > > This still proves a severe issue for my use case. Err... until you clarify how are you starting that pulseaudio daemon as root there is few things to do (and upstream won't want to ever hear about that issue). Then, that needs to be clarified at first (In reply to Alexander Tsoy from comment #27) [...] > Note entirely correct. "--system" switch is the way to run system-wide > pulseaudio instance. And you need special user and groups because pulseaudio > drops its privileges in that mode. Yeah, if you are running system-wide setup you need to rely on the provided init.d/conf.d files... anyway it's now completely unsupported by upstream and I am not sure if it will even work :/
Also... I am not sure if you have read the tons of warnings and "please don't use system-wide pulseaudio" that are shown while building and even running... and seeing that upstream killed all the referenced links I wonder if we should even kill that mode completely :|
With pulseaudio 7.0 and earlier, all I had to do was use 'pulseaudio --start' right before starting X for the first time (usually done from the console). That worked without issue. After 8.0, I've attempted running it multiple ways: 1.) The original way (--start from a DISPLAY-aligned root login VT) 2.) With pcm.default pulse / ctl.default pulse enabled in asound.conf so it inits/accesses pulse automatically (which shouldn't even be necessary, should it?) 3.) With pulseaudio --system (which, as mentioned, what I thought the "supported" means of running it as root would've been) 4.) The method I use for the test logs: running 'pulseaudio -vvv' from a VT (without letting the process into daemon mode) and recording the output. If --system _is_ unsupported, then I can throw out #3 on that list, at least... >SiGh<
(In reply to Megas of Vecanti from comment #32) > With pulseaudio 7.0 and earlier, all I had to do was use 'pulseaudio > --start' right before starting X for the first time (usually done from the > console). That worked without issue. You should have put this into the bug description because it is definitely not the way most people run pulseaudio. :) And I'm really surprised that pulseaudio worked this way for you, because IIRC it always refused to run as root, e.g.: # pulseaudio -D W: [pulseaudio] main.c: This program is not intended to be run as root (unless --system is specified). E: [pulseaudio] main.c: Daemon startup failed. # pulseaudio --start W: [pulseaudio] main.c: This program is not intended to be run as root (unless --system is specified). > > After 8.0, I've attempted running it multiple ways: > > 1.) The original way (--start from a DISPLAY-aligned root login VT) See above. I have no idea how this worked for you before. > 2.) With pcm.default pulse / ctl.default pulse enabled in asound.conf so it > inits/accesses pulse automatically (which shouldn't even be necessary, > should it?) This is not needed. You probably already have /usr/share/alsa/alsa.conf.d/50-pulseaudio.conf provided by alsa-plugins[pulseaudio]. > 3.) With pulseaudio --system (which, as mentioned, what I thought the > "supported" means of running it as root would've been) This should work, but is not recommended by upstream. If you want to give it a try, you can unmask and enable "system-wide" USE-flag and pulseaudio ebuild will create all necessary users/group and install openrc script. More info: https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/SystemWide/ > 4.) The method I use for the test logs: running 'pulseaudio -vvv' from a VT > (without letting the process into daemon mode) and recording the output. Same as 1.)
I would then go directly to ask to: https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss Maybe they will know how to achieve what you want (if possible still :/)
>You should have put this into the bug description because it is definitely not the way most people run pulseaudio. :) And I'm really surprised that pulseaudio worked this way for you, because IIRC it always refused to run as root [...] This actually hasn't _ever_ happened to me! pulseaudio has always run as root for me without any issue (other than the "this program is not intended to be run as root (unless --system is specified)" message. The daemon _runs_ afterwards; it just refuses all connections without any explanation. >This is not needed. You probably already have /usr/share/alsa/alsa.conf.d/50-pulseaudio.conf provided by alsa-plugins[pulseaudio]. I'm aware that it isn't needed--I thought it would improve matters (and I just double-checked: forcing pulseaudio from the application indeed seems to work, but it still refuses the connection X( ) >Maybe they will know how to achieve what you want (if possible still :/) I asked #pulseaudio about this issue on IRC, and they laughed at me for using Gentoo and openrc/consolekit. It didn't get anywhere past that point. I'm reluctant to attempt support via their mailing list for the same reason. =\ Perhaps if I link them to this bug, it could help matters (assuming they don't chide me for running pulseaudio as root/system-wide in addition to the above)... Before I try that, I'll build with USE=system-wide and see what happens, at least--
(In reply to Megas of Vecanti from comment #35) > >You should have put this into the bug description because it is definitely not the way most people run pulseaudio. :) And I'm really surprised that pulseaudio worked this way for you, because IIRC it always refused to run as root [...] > > This actually hasn't _ever_ happened to me! pulseaudio has always run as > root for me without any issue (other than the "this program is not intended > to be run as root (unless --system is specified)" message. The daemon _runs_ > afterwards; it just refuses all connections without any explanation. I was wrong. "pulseaudio --start" actually starts the daemon and it works (aplay/paplay produce the sound). But I didn't test if it works after starting X.
Also I don't understand why you run pulseaudio before X. If you use custom X session, then you can invoke "start-pulseaudio-x11" from your .xsession script. Maybe this will change something.
Well, I ran it that way because it used to work regardless and it caught the X server as it was was starting it. (Incidentally, running 'start-pulseaudio-x11' returns: Connection failure: Connection refused pa_context_connect() failed: Connection refused)
All right, I built with USE="system-wide" and I seem to have finally gotten some kind of clue from "pulseaudio -vvv --system"...Or at least I think it's a clue: D: [pulseaudio] dbus-util.c: Successfully connected to D-Bus system bus eab5f63f746b126e36fa1b6f57a7b1d7 as :1.24 E: [pulseaudio] main.c: Failed to acquire org.pulseaudio.Server: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.24" is not allowed to own the service "org.pulseaudio.Server" due to security policies in the configuration file Continuing to investigate.
All right. After doing some googling, I added the following lines within the <busconfig> tag (which was previously empty) in /etc/dbus-1/system.conf, then rebooted: <policy user="pulse"> <allow own="org.pulseaudio.Server"/> <allow send_destination="org.pulseaudio.Server"/> <allow receive_sender="org.pulseaudio.Server"/> </policy> 'pulseaudio -vvv --system', however, now returns the following in the log in an infinite loop until killed: I: [pulseaudio] client.c: Freed [number] "Native client (UNIX socket client)" I: [pulseaudio] protocol-native.c: Connection died. I: [pulseaudio] client.c: Created [number] "Native client (UNIX socket client)" D: [pulseaudio] protocol-native.c: Protocol version: remote 31, local 31 I: [pulseaudio] protocol-native.c: Got credentials: uid=0 gid=0 success=0 W: [pulseaudio] protocol-native.c: Denied access to client with invalid authentication data. _BUT! IN THE MIDDLE OF ALL THIS:_ Inexplicably, starting pulseaudio manually (with --start or otherwise, not as --system) now _receives connections and sees its own PID normally!_ 'pavucontrol', 'pulseaudio -k' and 'pulseaudio --check' all work. The only catch is that 1.) There's no audio because pulseaudio now only sees the HDMI connection on my motherboard and not the standard (hw) Audio Out where my speakers actually are (trying to work on that--think I can manage it somehow) 2.) Getting an application to access pulseaudio while the daemon is not explicitly running still returns "Connection Refused," as does 'start-pulseaudio-x11'. So this problem is now half-resolved. a log of 20-ish seconds of idle 'pulseaudio -vvv' output is attached below.
Created attachment 442742 [details] Log of ~20 seconds of pulseaudio startup, idle state and termination (as root user, post-dbus config adjustment)
Got pulseaudio to work via --start as root--it turns out it was detecting my video card's HDMI passthrough as the _only_ card through my asound.conf--For some reason non-root didn't pick them up. Strange, but resolved. However, autostart is still ignored for some improbable reason (any attempt to start pulseaudio if the daemon is not already running continues to be met with "connection refused"). This certainly isn't something I can diagnose--but as the definition of the bug has now changed significantly, I guess I should be filing a new bug with the present behavior in mind (failing to autostart with "connection refused" as root user). I guess that's it for this one, then. I appreciate your patience and I'm sorry for bothering you. X( Thanks.
