search

bus1 / dbus-broker

Linux D-Bus Message Broker
https://github.com/bus1/dbus-broker/wiki
Apache License 2.0
667 stars 78 forks source link

dbus-broker: pull in by multi-user.target properly #317

Closed poettering closed 1 year ago

poettering commented 1 year ago

So far nothing pulls in dbus-broker.service while the system is up, it's purely started via socket activation from dbus.socket. Which works fine in most ways, but is problematic when it comes to "systemctl isolate", which terminates all units nothing pulls in. Because without anything pulling in it will then be terminated even if its used in the current state and in the destination state.

This uses "multi-user.target" for pulling in the unit, which is the target unit that every regular boot (i.e. beyond "single-user mode") pulls in. (or with other words: in single user mode, we don't really need this, hence don't pull it in)

Fixes: https://github.com/systemd/systemd/issues/22022

dtardon commented 1 year ago

So far nothing pulls in dbus-broker.service while the system is up, it's purely started via socket activation from dbus.socket. Which works fine in most ways, but is problematic when it comes to "systemctl isolate", which terminates all units nothing pulls in. Because without anything pulling in it will then be terminated even if its used in the current state and in the destination state.

But that shouldn't happen anymore since https://github.com/systemd/systemd/pull/26388, should it?

dvdhrm commented 1 year ago

This feels like a workaround, doesn't it? No-one should care how dbus.socket is served. It should be an implementation detail, right? There are no outside dependencies to dbus-broker. So I wonder why the service is responsible to keep itself pulled into multi-user.target, when it doesn't care for any target except its socket?

poettering commented 1 year ago

So far nothing pulls in dbus-broker.service while the system is up, it's purely started via socket activation from dbus.socket. Which works fine in most ways, but is problematic when it comes to "systemctl isolate", which terminates all units nothing pulls in. Because without anything pulling in it will then be terminated even if its used in the current state and in the destination state.

But that shouldn't happen anymore since systemd/systemd#26388, should it?

Good point I guess. Seems a smarter person than me wrote that PR.

Anyway, let's close this one then.