Tanu Kaskinen <tanu.kaskinen at linux.intel.com> [2014-08-24 13:33:26 +0300]: > On Sat, 2014-08-23 at 08:41 -0600, Glenn Golden wrote: > > > > 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. > Glad you mentioned this because I can't reproduce it myself now, so it was probably an error in my earlier experiment. Looking at it again now, the rule does indeed appear to be as you originally stated, i.e. it falls back to HOME only if XDG_RUNTIME_DIR is unset. Apologies for the confusion. > > $HOME/.pulse is the old location. It's still used if it exists, to not > lose old user preferences. > Ah, ok. (And verified: Removed .pulse dir, unset XDG_RUNTIME_DIR and indeed it now creates xxxx-runtime in $HOME/.config/pulse.) > > > > 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. > OK. > > > > 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). > I'll take a shot at that, if you'll promise to be patient with the [possibly large number of] questions that will arise in the process of getting all the details straight. Given my time constraints, it might take several weekends of piecemeal writing until it's ready though. Also, I'd prefer to restrict such a blurb (at least initially) to narrowly describing only the rules by which PA determines the location of the pid file, rather than the more general "...about the different files that PA uses", because the latter would probably require more learning time on my part than I can commit to. > > ============================================================================= > > --check > > > > Attempts to query a running PA daemon > > This sounds like --check will attempt to connect to the daemon, which it > doesn't do. > >From what I could tell from the code, it sends kill(0) to the candiate pid and then interrogates the result of the kill() call (after first determining that the candidate pid actually refers to a running process). The above sentence was just an attempt to capture that briefly using the word "query". > > 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." > I'm going to respectfully push back again against that "calling user" phraseology, Tanu. It's just plain wrong and misleading, at least in the current implementation. You agreed earlier that to an experienced Unix user, the phrase "calling user" implies that the UID or EUID of the invoker of "--check" comes into play in determining which process to interrogate. But it does not, at least in the present implementation. Only the environment comes into play, and therefore the documentation should avoid stating otherwise. Suppose user xyz actually has a PA daemon running, and it was started from a process in which the environment had XDG_RUNTIME_DIR=/run/user/xyz. Later, he runs "pulseaudio --check" from a process which -- for whatever reason -- happens not to have XDG_RUNTIME_DIR set or set to another location. (This is exactly the situation that got me into this discussion in the first place.) In this case, "--check" (as currently implemented) says there is no daemon running, even though there clearly is "a PulseAudio daemon currently running for the calling user". By documenting how "--check" actually makes its determination _in the current implementation_, the reader can infer how _the current implemntation_ will behave in his particular situation. :) If the implementation changes such that the semantics of the option change, then the doc has to follow that. > 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). > Imo, that's not a "limitation": It's a description of how the option performs its task in the current implementation. :) If the implementation changes in the future -- for example, to utilize the UID/EUID -- then the doc should change along with it. Anyway... quite a bit of the above may become unnecessary to debate if the wiki blurb can provide the information about runtime files in a detailed way. So I would suggest not debating this further (and I will refrain from submitting any man page patch) until the wiki page on this topic is up and agreed upon. Then, I can patch the man page and cite it appropriately, and I think it can be short and sweet and satisfy everyone. Glenn
