[systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?

[Lennart Poettering]

On Wed, 22.10.14 12:44, Damien Robert (damien.olivier.robert+gmane at gmail.com) wrote:

> Colin Guthrie  wrote in message <m1rf8b$ojg$1 at ger.gmane.org>:
> > I want to rely on systemd --user to handle PulseAudio's activation
> > (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE
> > might start up their own session stuff and spawn some PA consuming
> > process before systemd --user has reached it's sockets.target and is
> > thus ready and listening on PA's native socket.
> 
> Interesting, does PA now support socket activation? Mine (pulseaudio 5.0)
> does not seem to support it.

Colin recently posted the patches for this on the PA ML.

> > Doesn't seem to be a problem on my machine here (it's working really
> > nicely actually!) but figured I should ask here too.
> 
> I have been using systemd user sessions for a long time, and it works really
> well, except for this policykit "bug":
> https://bugs.freedesktop.org/show_bug.cgi?id=67728
> 
> For instance since I start dbus under the user session, the dbus activated
> services also run inside it:
>    CGroup: /user.slice/user-1000.slice/user at 1000.service
>            ├─615 /usr/lib/systemd/systemd --user
>            ├─616 (sd-pam)  
>            ├─dbus.service
>            │ ├─  702 /usr/bin/dbus-daemon --session --address=systemd: --nofork 
>            │ ├─  835 /usr/lib/gvfs/gvfs-udisks2-volume-monitor
> 
> So udisks2 fails to mount my usb keys because it is not under an active
> session (since it is not launche from my active session) so it gets denied
> by policykit.

policykit really should get fixed there. it shouldn't try to do access
control for individual sessions but for users on specific
sessions. 

Lennart

-- 
Lennart Poettering, Red Hat