On 28 July 2016 at 16:33, Josh Triplett <j...@joshtriplett.org> wrote: > On Thu, Jul 28, 2016 at 10:04:41AM -0400, Felipe Sateler wrote: >> The story is as follows: >> >> 1. The default pulseaudio script loads module-udev-detect if it is available. >> 2. If it fails to load the daemon start fails. >> 3. The module fails to load if the udev daemon cannot be contacted. >> 4. I want pulseaudio to be installable and usable inside containers >> (contacting eg, remote sinks). >> 5. udev does not start inside containers. >> >> Upstream maintains that 3 is correct behavior. So to support >> containers without config changes by the user we need to either make >> sure module-udev-detect can be unavailable, or ignore udev load >> errors. The latter seems very undesirable, so that leaves us only >> making it possible to not install module-udev-detect. This also has >> the side benefit of not requiring a useless udev daemon inside the >> container. I hope this makes clear why this was implemented. > > It does, yes. > > 1, 3, 4, and 5 seem reasonable; 2 seems like the problem. Why does > ignoring module-udev-detect load errors (when the alternative is > completely failing to start) seem undesirable? Ideally, pulseaudio > should attempt to load module-udev-detect, and if that fails, load > module-detect instead rather than giving up.
Unfortunately the pulseaudio loader scripts are not very expressive so I don't think that is possible to achieve. I discussed this with upstream: <fsateler> tanuk: do you recall/know why does the default.pa loads module-udev under a .fail section? <fsateler> context is, people were complaining due to the module-udev split into a separate package <tanuk> fsateler: I don't remember, but I would guess that there's no reason for module-udev-detect to fail if it's present. <tanuk> fsateler: How is the package split related? <tanuk> module-udev-detect is guarded by .ifexists module-udev-detect.so <tanuk> So there should be no failure if the module isn't installed. <tanuk> fsateler: Hmm, maybe you were considering to remove that .ifexists check, and you'd like module-udev-detect to fail gracefully if udev isn't present/usable. <tanuk> fsateler: IIRC, this was discussed earlier (with you?), and my take-away was that while it has some drawbacks, it would be best if module-udev-detect would fail gracefully when it can't connect to udev. <tanuk> Nobody has submitted a patch, however. <fsateler> (sorry, got kidnapped into a meeting) <fsateler> tanuk: it is related because a user was asking why not simply ship the udev module, and have it fail if udev is not available <fsateler> or in other words, a reason for the split is that the daemon fails to start if the module fails to load <fsateler> so a user asked why would the daemon fail to start. and I didn't have an answer to that ;) <fsateler> tanuk: is it possible for a module to exit gracefully with "nothing to do" ? <tanuk> fsateler: Yes. <tanuk> Well, there's no special return code for "nothing to do". <tanuk> We have module-combine, which is deprecated and just loads module-combine-sink and then does nothing (module-combine still stays loaded). <tanuk> And module-hal-detect-compat loads module-udev-detect, and also requests itself to be unloaded after that. <fsateler> ok <fsateler> so I guess the way forward would be to make a patch for module-udev-detect to just: if (!connect_to_udev()) { return 0; } <fsateler> or something similar in spirit <tanuk> Yes. And include a comment why it's desirable to support systems that want to have module-udev-detect installed when udev isn't available. <fsateler> ok <fsateler> tanuk: do you mind if I copy paste this conversation into the bug log? <tanuk> Feel free. So the way forward would be to patch module-udev-detect to exit gracefully if udev is not present. One could even chain load module-detect if udev is not available. I guess patches welcome :). -- Saludos, Felipe Sateler