Re: Should libpam-elogind Provide libpam-systemd ?
On Tue, 06 Nov 2018 12:29:10 +0000, Ian Jackson wrote:
> Simon McVittie writes ("Re: Should libpam-elogind Provide libpam-systemd
> ?"):
>> Similarly, I think pulseaudio's Recommends is because pulseaudio is
>> frequently a systemd user service (one per uid). One of pulseaudio's
>> control protocols is that it can be sent commands via D-Bus IPC, but
>> again, that isn't going to work if the D-Bus session bus is
>> shorter-lived than the pulseaudio daemon.
>
> If you have multiple concurrent login sessions they each need their own
> pulseaudio setup, because sounds from one session should not appear in
> another.
No they don't, because pulseaudio can route different streams to
different output sinks. However, I agree that this handling is not
optimal right now, and you may end up with sound going somewhere
unexpected (but you can change it back!). I think discussion and patches
would be more than welcome upstream. However, please note that "ssh-ing
into the sound server and changing the volume" is something you can do
with the per-user pulseaudio but not with a per-session one (or at least,
not without some gymnastics).
I think there are three interrelated issues to have in mind when
discussing this:
1. Services should be automatically started, be that on first login (for
the per-user model), or on each login (for the par-session model). The
only solution we have right now is either systemd --user, or have people
put stuff in their login shell, because getty won't start dbus or
pulseaudio. Pulseaudio has an autostart feature to work around this
problem.
2. Access to shared resources should have reasonable mediation. Access to
devices is usually granted per-user. That is, a given user either has or
doesn't have access to /dev/snd/foo. There is currently no way to give
access to a certain set of processes but not others, if all the processes
are owned by the same user. With this plus autostart as noted above, you
get multiple pulseaudio instances that fight each other for sound device
access.
3. Supporting multiple instances per user is harder than allowing just
one. Dconf was already mentioned in this regard, and it is reasonable to
expect dconf to only allow one process per user, the same way you
wouldn't expect to be able to run multiple mysqld processes against the
same on-disk database. Similarly, any user service that writes anywhere
is bound to have these synchronization problems.
Solving problems 2 and 3 is hard. I think it is quite reasonable for some
upstreams to have decided that they will only support the per-user model.
In fact, these problems are so hard that there are suggestions that
access to sound devices should no longer be granted to users but to a
single system-wide daemon (pulseaudio itself is apparently not really
viable for this role for other reasons). Problems for blind users when
espeakup and pulseaudio fight each other for device access is one reason
this might be a good idea.
With my pulseaudio maintainer hat on, I welcome a bug report, but please
be explicit on what you actually think the bug is. If the bug is related
to problems 2 or 3, I don't think I can help you much. If you think the
bug is just about avoiding broken Recommends, then please see #883756, as
it is not quite trivial to solve (I want systemd --user integration by
default, and unfortunately this currently means manual action if you want
to disable it).
--
Saludos,
Felipe Sateler
Reply to: