Web lists-archives.com

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