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. -- Saludos, Felipe Sateler
