[systemd-devel] [PATCH] analyze/run: Use bus_open_transport_systemd instead of bus_open_transport.

[Thomas Bächler]

Am 24.02.2014 17:10, schrieb Lennart Poettering:
> On Fri, 21.02.14 11:55, Thomas Bächler (thomas at archlinux.org) wrote:
> 
>> Both systemd-analyze and systemd-run only access org.freedesktop.systemd1
>> on the bus. This patch allows using systemd-run --user and systemd-analyzeefau
>> --user even if the user session's bus is not properly integrated with the
>> systemd user unit.
> 
> I am not convinced this is really desirable. The private socket exists
> solely to make sure we cann communicate during really early boot and
> during late shutdown with it, but neither systemd-analyze nor
> systemd-run really appears to be tools that need to support that?

I am not saying it is desirable (it is not). I am saying it may be
necessary.

Short reason: We don't live in a perfect world yet.

Long reason (sorry, this is going to be really long):

Let me first emphasize that I don't have PID1 in mind. If this was in
any way necessary for the --system case, something would be quite
broken. My problem is only with the user instance. I first noticed that
running 'systemd-run --user ...' resulted in the message

 Failed start transient unit: Process org.freedesktop.systemd1 exited
with status 1

(a bit cryptic, but I understand what it's about.) My thoughts about this:

1) (non-kdbus case)

Until kdbus is complete and the default, it is rather hard to integrate
the user instance with the actual user session. While we can now (with
209) import the environment into systemd, there is no way to import it
into dbus-daemon. Thus, if we install a unit that sets up dbus-daemon
for the user instance and import DBUS_SESSION_BUS_ADDRESS=/run/... into
the desktop session, all dbus-activated services will lack necessary
environment variables like DISPLAY, KDE_FULL_SESSION and similar. I have
used such a setup for a while, and KDE loses functionality.

Even if we could work around this problem, this setup does not work out
of the box, since systemd does not ship the required dbus units.
Therefore, systemd-run --user and systemd-analyze --user can never work
out of the box.

2) (kdbus case)

In the (hopefully) not so far future, we'll have kdbus. This will
improve the situation considerably:

a) importing the environment into systemd will work and actually help
result in the proper environment being provided to the bus-activated
services.
b) a generator will convert all dbus service files into the required
systemd units.

All that remains is that one sets up the desktop to actually export the
environment to systemd and to use the dbus socket provided by
bus-proxyd. This isn't perfect yet (the desktop should integrate with
systemd properly on its own), but it's usable.

Still, this requires manual user intervention by someone knowledgable
and thus, systemd-run --user and systemd-analyze --user still won't work
out of the box.

3) (why not?)

It doesn't hurt anyone. Both tools only ever connect to
org.freedesktop.systemd1, never to anything else. Whether we connect via
the "normal" bus or the private one does not matter, the functionality
provided will be the same.

Thus we fix a few rather common problems (which will disappear over
time, but not tomorrow) with a simple change that does not harm, but is
only "undesirable" for philosophical reasons.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140224/7a812b2a/attachment.pgp>