#785: No or only random connections to PulseAudio server after `pulseaudio -k`.
--------------------------+-------------------------------------------------
Reporter: PaulePanter | Owner: lennart
Type: defect | Status: new
Milestone: | Component: daemon
Resolution: | Keywords:
--------------------------+-------------------------------------------------
Comment(by coling):
Replying to [comment:2 PaulePanter]:
> Replying to [comment:1 coling]:
> > Chances are your X11 properties are somehow out of sync with the
running PA. This shouldn't really happen but does pax11publish -r help?
>
> Did you mean `pax11publish -e` to export the information to the X11 root
window?
That would work too, but -r removes the properties. At this point PA would
likely fallback to the env vars of conf file (both of which are unlikely
to be set unless you are specifically setting them).
> I did not know about `pax11publish`. The manual page lists `xprop -root
| grep ^PULSE_` to dump the raw information. `pax11publish -d` seems to
output the `Server` and `Cookie` nicely formatted.
>
> So with the PulseAudio server started by my GNOME session(?) I got.
It's started via XDG (to which Gnome session init conforms) at X11 login.
The start-pulseaudio-x11 script is run and as a result the various x11
modules are loaded into the PA server. These modules are purely optional
and only provide increased functionality for X11 users (PA can happily be
started on the console too).
> Killing `pulseaudio -k` and starting PulseAudio `pulseaudio -vvvvv` with
`autospawn = no` resulted in the following.
> So the PA server credentials were not published to the X root window.
Wondering why, I noticed in the log or with `list-modules` in `pacmd` that
`module-x11-publish` was not being loaded. It is commented out in
`/etc/pulse/defaul.pa`.
It's not meant to be loaded via default.pa. See the start-pulseaudio-x11
script. As mentioned above PA should start and work via non-x11 sessions
too.
> This was done in
[http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=3888bfcccd8324d23a7bc31ebb2d8063d9da1aaf
commit 3888bfcccd8324d23a7bc31ebb2d8063d9da1aaf] with the commit message
»enable exit-on-idle by default«. I cannot grasp the reasons behind this
though. Maybe because it should not be loaded when running without X and
one is supposed to use `start-pulseaudio-x11` if a X server is running.
Yes, that is the logic.
> I do not know why `module-x11-publish` is loaded when my system starts
See above. start-pulseaudio-x11 is started at your X11 login via XDG.
> Anyway loading this module manually
The cookies all match so it's likely not the problem.
> 1. Can `module-x11-publish` be loaded conditionally if a X server is
running? It seems to be the task of the desktop environment, but as we
have seen sometimes the PA server is killed and started automatically
(`autospawn = yes`) or manually (`autospawn = no`).
Well it's generally not a problem. PA shouldn't crash (if it does we
should fix those problems) and if you run PA manually you should be aware
of what you are doing etc. etc. I'm not sure what effect including the
modules in the default.pa within a .nofail block would have tho'. It may
be enough to "just work" for the majority of cases.... I can think of some
problems tho' e.g. connecting to a remote machine via X11 from a machine
without PA, starting PA remotely, getting the root window (via SSH)
properties set and then logging out. The initial machines PA related
preferences will then be all messed up.
> To do some further tests I killed the PA server again and tried your
suggestion to export the PA server credentials manually after starting the
PA server again (without `module-x11-publish`).
>
> {{{
> $ pax11publish -e
> PULSE_COOKIE(STRING) =
"aa0cf9aa0ba2703f23be6741b64a9521bc460d6943b03c878fba145ce8823ff46253a04361b89cffd1a339293f09d1ae446297ca43129d58214f27e3acd54d643803da7cf9aca2455fac684f2323856b10d76186cdbbca8942e12d0c0f64f5202ac1d15714f6afc6335d6b3853ffe1024f1422e1d0390a44c4da8e4b02e56e270a23e4f0e95504cd22a1c0c080c01b9f3f7de653c8e5d25d0308e46d24439b66a5bc9363830eb8fe0b8e4e57483427437307e864528ea304d0f5f6c382e4113b7bed540371170ec1dab36f1d75dce14671c4a69871d8af336c47b1c1a0822a9d7066507aff52de158b7b796afcde280919a0dbce5a69fbc40cbc87d43edf1c20"
> PULSE_SERVER(STRING) = "myhostname"
> }}}
> {{{
> $ pax11publish -d
> Server: myhostname
> Cookie:
aa0cf9aa0ba2703f23be6741b64a9521bc460d6943b03c878fba145ce8823ff46253a04361b89cffd1a339293f09d1ae446297ca43129d58214f27e3acd54d643803da7cf9aca2455fac684f2323856b10d76186cdbbca8942e12d0c0f64f5202ac1d15714f6afc6335d6b3853ffe1024f1422e1d0390a44c4da8e4b02e56e270a23e4f0e95504cd22a1c0c080c01b9f3f7de653c8e5d25d0308e46d24439b66a5bc9363830eb8fe0b8e4e57483427437307e864528ea304d0f5f6c382e4113b7bed540371170ec1dab36f1d75dce14671c4a69871d8af336c47b1c1a0822a9d7066507aff52de158b7b796afcde280919a0dbce5a69fbc40cbc87d43edf1c20
> }}}
>
> So it looks a little bit different then from the beginning. `Cookie` has
the same value, but the other information are all different or are not
set. The problem with `gstreamer-properties` and `mplayer` are the *same*
as in my original report, i. e. the connection is refused for them. I
found out that `paplay` has the same problem.
Likely all PA clients will have the same problem. This is not something
that should affect one client but not another unless that client is
specifically written to do something strange.
What is interesting here tho' is the fact that the socket path is not
published. This means that in order for these settings to work, you *MUST*
enable TCP connections. This seems very strange and I can't help but
wonder why the local socket path is not included here..... (it seems this
is the underlying problem with this particular "connection refused" which
may or may not be the same as the original problem you are reporting).
> After killing this PA server (started with `pulseaudio -vvvvv`) with
`pulseaudio -k` the credentials are not removed.
That's expected. The PA server didn't set them, the pax11publish command
did. So PA server will not remove them, the pax11publish -r command
should.
> {{{
> $ pulseaudio -k
> $ pax11publish -d
> Server: myhostname
> Cookie:
aa0cf9aa0ba2703f23be6741b64a9521bc460d6943b03c878fba145ce8823ff46253a04361b89cffd1a339293f09d1ae446297ca43129d58214f27e3acd54d643803da7cf9aca2455fac684f2323856b10d76186cdbbca8942e12d0c0f64f5202ac1d15714f6afc6335d6b3853ffe1024f1422e1d0390a44c4da8e4b02e56e270a23e4f0e95504cd22a1c0c080c01b9f3f7de653c8e5d25d0308e46d24439b66a5bc9363830eb8fe0b8e4e57483427437307e864528ea304d0f5f6c382e4113b7bed540371170ec1dab36f1d75dce14671c4a69871d8af336c47b1c1a0822a9d7066507aff52de158b7b796afcde280919a0dbce5a69fbc40cbc87d43edf1c20
> }}}
>
> 2. It looks like `pax11publish` fails to publish the correct credentials
as `module-x11-publish` is doing. Is that a bug?
I'm not sure. Perhaps. It depends on what pax11publish is really meant to
do. I guess it's used primarily as a tool for connecting remotely so
perhaps doesn't need to worry about local connections. But by the same
token, I can't think of a reason why it would *not* include the local
socket path either.
> >Or running start-pulseaudio-x11 after killing PA
>
> That one works because `module-x11-publish` is loaded when starting PA
server with `start-pulseaudio-x11`.
I know, that's why I suggested pax11publish -r or this method. -r would
remove all X11 properties and basically take the X11 part of the config
completely out of the equation...
> {{{
> $ LANG=C start-pulseaudio-x11
> I: main.c: Daemon startup successful.
> $ pax11publish -d
> Server:
{1572dc2ca76ca04c3351599547f539a6}unix:/home/joe/.pulse/1572dc2ca76ca04c3351599547f539a6-runtime/native
> Cookie:
aa0cf9aa0ba2703f23be6741b64a9521bc460d6943b03c878fba145ce8823ff46253a04361b89cffd1a339293f09d1ae446297ca43129d58214f27e3acd54d643803da7cf9aca2455fac684f2323856b10d76186cdbbca8942e12d0c0f64f5202ac1d15714f6afc6335d6b3853ffe1024f1422e1d0390a44c4da8e4b02e56e270a23e4f0e95504cd22a1c0c080c01b9f3f7de653c8e5d25d0308e46d24439b66a5bc9363830eb8fe0b8e4e57483427437307e864528ea304d0f5f6c382e4113b7bed540371170ec1dab36f1d75dce14671c4a69871d8af336c47b1c1a0822a9d7066507aff52de158b7b796afcde280919a0dbce5a69fbc40cbc87d43edf1c20
> $ LANG=C paplay song.flac
> $ # plays until end
> }}}
So this suggests that you do not have TCP support enabled. That's fine. I
guess you shouldn't run pax11publish (except with the -r command) until
the scope of that tool has been confirmed and we can either open a bug or
document it.
> >(or after running it in the terminal manually - i.e. run start-
pulseaudio-x11 in another term while the -vvv manual run is happily
sitting and waiting)
>
> I do not know what you mean by »sitting and waiting«. But if I run
`pulseaudio -vvvvv` before in another terminal, running `start-
pulseaudio-x11` does not work.
Are you sure?
> {{{
> $ LANG=C start-pulseaudio-x11
> I: main.c: Daemon startup successful.
> [(With `--daemonize=no` we get the reason.) E: pid.c: Daemon already
running.]
> Failure: Module initalization failed
> }}}
That doesn't mean the command wasn't successful. Using daemonize=no is
going to create problems..... please don't turn that on. The start-
pulseaudo-x11 script is *not* just trying to start the PA server. It will
start it if it is not running, but it will happily accept the fact that it
is started already. If you subsequently get a module initialisation
problem, then it suggests you have actually run the script *twice* or have
the x11 modules listed in default.pa which is non-standard (as loading two
of the X11 modules for the same $DISPLAY is not meant to work, so failing
to load the module is expected).
> 3. This error message is in my opinion confusing. »E: pid.c: Daemon
already running.« should be printed as the error.
It's not the error. The whole point in the --start argument is to start
the server if it's not running and to be quite happy if it's not. Don't
set daemonize=no and no error is printed (as is correct - daemon already
running is a good and valid outcome!).
> > Both methods should fix up the X11 settings that the client uses when
connecting... Not certain this is the problem, but I suspect it's
something in this area.
>
> I think you were spot on and probably the instructions in the Wiki
should be changed on how to start a PA server with a X server running.
There is not much to tell here. I think you've managed to over analyse the
problem somewhat by not doing pax11publish -r at the beginning as I
suggested and then didn't really appreciate what all the various scripts
etc were meant to do and where the x11 modules should be used. I guess
it's valid to put this info on the Wiki, but it's not information you
generally want regular users to see as a first port of call. 99.99% of
users wont care or want to know about this. It's only when you get into
problems and fiddle with configurations that you get into this situation.
So what I would do is this:
1. Make sure your default.pa and daemon.conf are pristine and what we
ship. Do not try to load X11 modules in there.
2. Boot up normally.
3. Before issuing your first pulseaudio -k, check {{{xprop -root | grep
PULSE}}} to see what the values are and ensure that a socket path is
indeed present, not just a hostname.
4. Issue pulseaudio -k, pulseaudio -vvvv
5. Things should still work (the socket path shouldn't change when
stopping and restarting the PA server. If it does then this is where your
problem lies).
6. If things do not work, issue {{{pax11publish -r}}} to *remove* the X11
properties. Confirm with xprop command.
7. Do things work now?
8. If things do not work, try {{{start-pulseaudio-x11}}} (keeping the
dameon running under -vvvv in your other terminal). The first time this
script is run it should *not* produce any errors. Do things work now? If
so, then the problem is very likely in your client.conf file (either
/etc/pulse/client.conf or ~/.pulse/client.conf). It likely has a default-
server specified. Under normal circumstances the X11 properties will take
configuration precedence as part of a regular login. When you issue
{{{pulseaudio -k}}} these properties will be deleted by the x11-publish
module when it unloads. When you run {{{pulseaudio -vvvv}}} the properties
will not be set (as expected) and as such we will fall back to the default
case (check env vars, x11 props, client.conf then built in defaults). The
built in defaults should work, but I'm guessing it's getting tripped up at
the client.conf stage.
I hope that make sense. It's long winded I appreciate and the
configuration steps are a little confusing to get your head round. I wrote
all this up here:
http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-
part-2-pulseaudio/
> PS: I hope publishing my PA cookie in this ticket will not have any
security consequences for me. If you please tell me.
Well if you enable a public facing tcp connection to PA someone could
evesdrop on all your sound (VoIP calls etc.) or play some really bad tunes
on your speakers.... it's the latter I'd be most worried about :p Just
delete your ~/.pulse-cookie and restart and it'll generate a new one.
--
Ticket URL: <http://pulseaudio.org/ticket/785#comment:3>
PulseAudio <http://pulseaudio.org/>
The PulseAudio Sound Server
_______________________________________________
pulseaudio-tickets mailing list
pulseaudio-tickets@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-tickets
