On Sat, Oct 6, 2012 at 3:46 PM, Thomas Bächler <tho...@archlinux.org> wrote: > Am 06.10.2012 23:53, schrieb Kok, Auke-jan H: >>> Furthermore, systemctl was unable to do anything - not even 'systemctl >>> --user exit' worked - it couldn't find systemd on the bus, as it refuses >>> to look for the bus unless sd_booted() is true. You can send the signal >>> manually, but that is not what you want. >> >> you explicitly have to set DBUS_SESSION_BUS_ADDRESS no matter what. >> Even with systemd running as pid 1 that is required. Perhaps that is a >> bug in itself. > > No, I took care of a dbus session. I could even (manually, using qdbus) > send the right dbus signal to the systemd user instance so it would exit > itself, so that part worked.
Forgive me for not knowing Qt, but does that set DBUS_SESSION_BUS_ADDRESS, and enable dbus.socket under the systemd --user instance? Did you start a dbus-daemon manually, or let systemd activate it? > Unless systemd --user is actually supposed to work in a non-systemd > environment, and someone actually fixes the problems that make it > entirely non-functional, my patch is the only sane thing to do. this I pertinently disagree with. You have no idea if folks are interested in running systemd --user outside of a system systemd. I would even strongly encourage people to do that and make it work, since it allows us to enable systemd user sessions for desktop startup in distributions that don't have proper systemd as system mananger integrated. We have a great opportunity to get more folks using systemd and test deployment of user sessions in e.g. gnome/KDE, and instead of tackling the problem this patch ... kills it. And really, a nice big fat warning message would just do fine. It's not like you stumbled on this debugging a server crash, you were just experimenting. Auke _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
