[pulseaudio-tickets] [PulseAudio] #785: No or only random connections to PulseAudio server after `pulseaudio -k`.

[PulseAudio]

#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