<p dir="ltr"><br>
On Oct 23, 2014 1:54 AM, "Lennart Poettering" <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote:<br>
><br>
> On Wed, 22.10.14 12:44, Damien Robert (<a href="mailto:damien.olivier.robert%2Bgmane@gmail.com">damien.olivier.robert+gmane@gmail.com</a>) wrote:<br>
><br>
> > Colin Guthrie  wrote in message <m1rf8b$ojg$<a href="mailto:1@ger.gmane.org">1@ger.gmane.org</a>>:<br>
> > > I want to rely on systemd --user to handle PulseAudio's activation<br>
> > > (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE<br>
> > > might start up their own session stuff and spawn some PA consuming<br>
> > > process before systemd --user has reached it's sockets.target and is<br>
> > > thus ready and listening on PA's native socket.<br>
> ><br>
> > Interesting, does PA now support socket activation? Mine (pulseaudio 5.0)<br>
> > does not seem to support it.<br>
><br>
> Colin recently posted the patches for this on the PA ML.<br>
><br>
> > > Doesn't seem to be a problem on my machine here (it's working really<br>
> > > nicely actually!) but figured I should ask here too.<br>
> ><br>
> > I have been using systemd user sessions for a long time, and it works really<br>
> > well, except for this policykit "bug":<br>
> > <a href="https://bugs.freedesktop.org/show_bug.cgi?id=67728">https://bugs.freedesktop.org/show_bug.cgi?id=67728</a><br>
> ><br>
> > For instance since I start dbus under the user session, the dbus activated<br>
> > services also run inside it:<br>
> >    CGroup: /user.slice/user-1000.slice/user@1000.service<br>
> >            ├─615 /usr/lib/systemd/systemd --user<br>
> >            ├─616 (sd-pam)<br>
> >            ├─dbus.service<br>
> >            │ ├─  702 /usr/bin/dbus-daemon --session --address=systemd: --nofork<br>
> >            │ ├─  835 /usr/lib/gvfs/gvfs-udisks2-volume-monitor<br>
> ><br>
> > So udisks2 fails to mount my usb keys because it is not under an active<br>
> > session (since it is not launche from my active session) so it gets denied<br>
> > by policykit.<br>
><br>
> policykit really should get fixed there. it shouldn't try to do access<br>
> control for individual sessions but for users on specific<br>
> sessions.</p>
<p dir="ltr">Wasn't this already fixed in polkit.git recently?</p>
<p dir="ltr">-- <br>
Mantas Mikulėnas</p>