On Sat, 2014-08-23 at 08:41 -0600, Glenn Golden wrote: > Tanu, Felipe, > > Writing up some text now for the --check option. Further below is what I have > so far. A lot longer than the original, but it attempts to cover everything > that has been mentioned in the thread thus far. > > However, while verifying some of the statements made in the proposed text (by > doing experiments with $XDG_RUNTIME_DIR and $HOME settings and looking at debug > output) I found some discrepancies between the experiment results and some > statements made earlier in the thread. Can you comment on these please: > > 1. > ...if XDG_RUNTIME_DIR isn't set at all, then the check assumes that > > HOME[1] is set correctly. > > The experiments seem to indicate that if XDG_RUNTIME_DIR is EITHER unset > OR if it points to a directory or pid file which is inaccessible or non- > existent, then the $HOME approach is used. That's surprising to me. Falling back to $HOME if $XDG_RUNTIME_DIR is set but doesn't work doesn't seem like a good idea. > 2. In the latter case ($HOME approach) it seems that on my system (Arch linux) > the directory in which the xxxx-runtime file is located is not > $HOME/.config/pulse (as was stated earlier in the thread), but $HOME/.pulse. > Are there any other possibilities? $HOME/.pulse is the old location. It's still used if it exists, to not lose old user preferences. > 3. Also pertaining to the $HOME approach, in which the runtime dir is named > as "xxxx-runtime", where xxxx is a hex string: I'd like to at least say > a few words about what that "xxxx" is. Is it a per-session ID? Or per-seat? > Or what? It's the machine-id (defined in /etc/machine-id). The reason for having that in the file name is that the home directory may be on a network file system, and used on multiple machines simultaneously. With the machine-id prefix, PulseAudio running on machine A will see a different set of files than PulseAudio running on machine B, so they don't conflict with each other. If /etc/machine-id doesn't exist, then the hostname is used as the prefix instead. > 4. Even better than answering 1-3: Do you know of any extant PulseAudio doc > that could be cited which describes in detail the way in which the > combination of > > - $XDG_* envars > - "standard" envars ($HOME, e.g.) > - OS/installation conventions > > interact to lead to the sequence of candidate paths for the runtime > directory when the daemon starts? No, there's no such document. I suppose it wouldn't be a bad idea to have a page in the wiki about the different files that PulseAudio uses, and how they are located. I can give you write access to the wiki if you wish (for spam reasons, the freedesktop.org wiki doesn't allow random people to register themselves). > If such a document exists, then the > --check option blurb could avoid the need to lay it all out in gory detail > and simply say something like "The process ID of the daemon to be queried > is determined in accordance with [1]", and then add a REFERENCES subsction > to the man page and list [1] as that extant doc. > > In the absence of any such extant detailed doc, I honestly don't see any way > to accurately and usefullly describe the operation of --check without including > that detail in the blurb itself, as is done below. Anything less just leaves > opportunity for confusion. > > Anyway... here's what I have so far. Text in square brackets is meta-stuff. > ============================================================================= > --check > > Attempts to query a running PA daemon This sounds like --check will attempt to connect to the daemon, which it doesn't do. I suggest: "Checks whether a PulseAudio daemon is currently running for the calling user (but see limitations below). The exit code is zero if there's a daemon running." Then explain the limitations, i.e. the current implementation relies on a pid file, and locating that requires $XDG_RUNTIME_DIR or $HOME to match the environment of the running daemon (an explicit warning about su/sudo not updating $XDG_RUNTIME_DIR would be good). -- Tanu
