On Sun, 2014-08-24 at 07:55 -0600, Glenn Golden wrote: > 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: > > > 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. I don't mind questions, especially if they result in documentation. > 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. Sure. I made a template: http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Files/ To edit, click "Edit". You'll be asked for a user name and password, which I'll send privately. > > > > ============================================================================= > > > --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. We should document what the purpose of the --check operation is. The implementation details don't matter, unless there are some caveats that the user should be aware of. I have so far thought that the purpose of --check is to check if there's a daemon running for the calling user, but actually, I don't think that's correct. Checking whether there's a daemon running for the calling user makes sense only if there can be only one daemon running for one user, and that's not the case (one example would be a scenario where the user has one regular daemon running, and then the user runs a PulseAudio test suite that starts another daemon for the tests under the same user but in a different environment). I find it hard to accurately describe the real purpose. It's something like "check if there's a daemon running in the current environment". I think in the current implementation "the current environment" means of the effective UID and the XDG_RUNTIME_DIR and HOME environment variables. I'm not sure if the definition of "the current environment" is an implementation detail, or something that can be assumed not to change. It seems more like an implementation detail. If you wonder why I included the effective UID in the environment, even if the code doesn't currently take it into consideration, the reason is that the result depends on the effective UID too. Running --check under different users in with the same environment variables results in different answers, if only one of the users has access to the runtime directory. -- Tanu
