[systemd-devel] [PATCH 1/2] core: Refuse to run a user instance when the system hasn't been booted with systemd.

[Thomas Bächler]

Am 07.10.2012 02:48, schrieb Kok, Auke-jan H:
>> 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, 

'qdbus' is just like 'dbus-send', but simpler to use.

> 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?

I started a dbus session manually, exported the DBUS_SESSION_BUS_ADDRESS
and systemd --user successfully picked up on it.

As I said, dbus was NOT the problem here.

Btw, there is no dbus.socket under /usr/lib/systemd/user in my system
and I have no idea what it would look like. On my systemd-booted system,
the user instance would use an existing session dbus as expected and
there is no need for systemd to spawn its own one.

>> 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.

This is not about what users want, this is about the status quo. And the
status quo is that a systemd user instance on a non-systemd system is
completely non-functional.

> 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.

You are not listening to me: 'systemd --user' does not work in this
scenario, but acts as if it would. This is broken behaviour.

As I said multiple times, 'systemctl --user' explicitly refuses to get
on dbus when sd_booted() returns false (read the code, it is not hard to
find in there [1]). This means that there is no way to use systemctl to
control your user instance. What is the point in being able to run it then?

All my patch does is match systemd's behaviour to systemctl's behaviour.
It is about being consistent. It is about not claiming that things work
which actually don't work.

> 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.

It is already dead. Everyone trying it will simply say "uh, this doesn't
work at all" and quit.

If you make this work again, you can include patch that reverts this
one. But leaving it as it is makes no sense at all.

> And really, a nice big fat warning message would just do fine.

Yes, let's add the following warning:

"Warning: This does not work at all. You are free to watch this daemon
do nothing for as long as you like. And by the way, the only way to kill
it is with SIGKILL."

> It's not like you stumbled on this debugging a server crash, you were
> just experimenting.

I do not understand what you are trying to say here.

I actually wanted to do what you described above: I wanted to use a
systemd user instance on a non-systemd system (where the init system is
not under my control). I have been told by multiple people on IRC that
this is not intended to work at all, and that this has been stated
multiple times on the mailing list (without being given an explicit link).


[1]
http://cgit.freedesktop.org/systemd/systemd/tree/src/systemctl/systemctl.c#n279

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