On Mon, Sep 15, 2014 at 12:09 PM, Felipe Sateler <fsateler at debian.org> wrote: > On Mon, Sep 15, 2014 at 5:50 AM, Tanu Kaskinen > <tanu.kaskinen at linux.intel.com> wrote: >> On Wed, 2014-09-10 at 09:51 -0300, Felipe Sateler wrote: >>> On Wed, Sep 10, 2014 at 6:18 AM, David Henningsson >>> <david.henningsson at canonical.com> wrote: >>> > >>> > >>> > On 2014-04-13 20:21, Balint Reczey wrote: >>> >> >>> >> Hi, >>> >> >>> >> This patch has been contributed through Debian's bug tracker. >>> >> Please review it and consider accepting it to the project's code base if >>> >> you find it useful. >>> >> >>> >> Thanks, >>> >> Balint >>> > >>> > >>> > Hi Balint, >>> > >>> > I wonder if the above can cause a problem if: >>> > >>> > 1) User starts X session + PulseAudio >>> > 2) The same user switches to something else (e g, a VT or SSH session), >>> > logs in, and starts using the PA daemon >>> > 3) User logs out of X session >>> > >>> > Now PulseAudio is killed, while still being in use by the user. >>> >>> I would think the daemon is per-session, not per-user, given that >>> (until systemd --user works) we cannot track user stuff across >>> sessions. >> >> We can, module-systemd-login exists for that purpose. It creates a >> client object for each session that the user has. As long as there are >> any client objects in PulseAudio, the server won't shut down >> automatically. When the last client exits, PulseAudio will exit after a >> delay (20 seconds by default). > > And what happens if I log in to X, switch to a VT, logout from X and > login again to X? As I understand the current status, the dbus session > is tied to the X server, so there should be a new session bus in thi > case. Does pulseaudio handle this situation correctly? (eg, will > bluetooth devices work after this?) > > > >> >>> But the core reason this patch is applied is that if pa is shutdown >>> after alsa, pa will store a volume of 0 (as alsa shutdown mutes all >>> the cards), so on reboot you have a 0 volume desktop. I think this is >>> a worse outcome than the alternative, as it is terrible for >>> accesibility. >> >> Why does PulseAudio shut down after alsa? > > I don't know how this goes now that most people are switching to > systemd. But in the old sysvinit days, the pulseaudio process would be > left running after X ended. If X was terminated due to system > shutdown, there is a possibility that the ALSA shutdown script will > run with the pulseaudio daemon running, which will mute the devices. > After that, the pulseaudio process is terminated by the general system > process killer. Since pulseaudio noticed the muting done by the ALSA > script just earlier, it stores that in its database, resulting the > muted-at-boot problem on the next boot. > >> Could this be solved by >> changing the auto-exit delay from 20 seconds to zero? > > Probably, depending on the level of parallelization achieved by > systemd. Assuming that the logind client exits at the same time X is > exiting, and that systemd does not shutdown system services until X > has finished exiting, the problem should be avoided. If the assumption > doesn't hold, then the race still exists although less likely. > > Thinking about this, I don't really see a big difference between > "exiting with the X server" and "exiting with the user session". Both > should kill pulseaudio sufficiently early. And I forgot to add: but this will not work on non-systemd systems, so an alternative solution for them is needed as well. -- Saludos, Felipe Sateler
