Am 24.02.2014 17:10, schrieb Lennart Poettering: > On Fri, 21.02.14 11:55, Thomas Bächler (tho...@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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel