Much software that uses D-Bus is not handling the case that the D-Bus daemon is restarting, because doing so adds a lot of complexity (it's really convenient, to just rely on D-Bus working *all the time* and not handle the case that it could fail at any time). NetworkManager doesn't handle that, so it needs to be restarted when the D-Bus daemon gets restarted. Theoretically this could be implemented, but it's high effort for little use.

(upstream patches welcome though).

> When restarting dbus.service unit, (due to failure, patching, etc.)

dbus.service is a central part of the system. If you restart it, you must restart most services that use D-Bus. That basically amounts to a full reboot, because so many services are affected.

That's not different from kernel. If kernel fails or requires an update, you also need to reboot (kernel live patching aside, which is not available to user-space processes and also limited for kernel).


That we split a part of D-Bus out to a user-space process, has advantages and disadvantages (see kdbus). One advantage could be, that the D-Bus part is independent and you could restart it on failure. A bit like with a micro kernel approach, where the kernel is split into individual services that may fail and restart independently. So this seems something that would be nice, but it's then the dbus-daemon's responsiblity to restart/recover in a transparent manner. It cannot be, that every client is affected by the restart and needs to implement it (at significant complexity). IMO, if the restart case is important, then dbus-broker needs to handle that transparently, without requiring every client to handle the complexity of implementing it: https://github.com/bus1/dbus-broker/issues/93 .



Maybe if you list exactly why you restart dbus.service, we could suggest how to do it or what to do otherwise. Probably the likely solution will be to reboot. If you restart because of package update, then the dbus-daemon package should be mostly boring and not update frequently (when it does, reboot). If you restart because of bugs in dbus.service, the right solution is to fix the bugs. If you restart because running out of resources/memory, you probably want to allocate enough resources to dbus.service for that not to happen (and/or rate limit how much clients -- based on the user ID -- can use).


This is a WONTFIX.

> this is not important for the customer, I just found that when "playing" with dbus.
> ...
> "Fix the bugs" is easy to say, but having to reboot a production system several times in order to troubleshoot a potential bug is not.

Is this just hypothetically speaking? Or what was the real world issue (where restart of dbus.service was necessary and reboot was not a good option).

Btw, the (current) workaround is `systemctl restart dbus.service NetworkManager.service`. Also, NetworkManager is probably not the only offender and other services might also require a restart. By restarting dbus.service, you might introduce other issues that interfere with "troubleshoot a potential bug". I wouldn't trust the system after `systemctl restart dbus.service` to show the bug I am hunting. I would just reboot. Of course, in production that may be problematic either way.

> If you cannot fix NetworkManager properly (from high look it's just a matter of reconnecting)

"cannot" is too strong of a word. It seems not trivial, while also not really necessary.

"BindsTo=dbus.service" is probably a good idea in the meantime!


My point is that restarting dbus.service is not something that you would usually do (I don't recall ever needing that myself). So the simple answer to this issue is "just don't do it -- reboot if you really need". It would be interesting to learn where this is used in practice. Thank you!

Since Thomas agrees to add BindsTo, I am also fine with adding this. Any additional work does not seem to have the impact that justifies the effort. So proposed acceptance criteria:

Given a RHEL system
When running grep BindsTo=dbus.service /usr/lib/systemd/system/NetworkManager.service
Then BindsTo=dbus.service is shown

(In reply to Till Maas from comment #7)
> Since Thomas agrees to add BindsTo, I am also fine with adding this. Any
> additional work does not seem to have the impact that justifies the effort.
> So proposed acceptance criteria:
> 
> Given a RHEL system
> When running grep BindsTo=dbus.service
> /usr/lib/systemd/system/NetworkManager.service
> Then BindsTo=dbus.service is shown

I would rather say:

1)
Given NetworkManager running on a systemd system
Given NetworkManager cannot handle reconnecting to the dbus daemon
When dbus daemon is stopped
Then NetworkManager is also (automatically) stopped


2)
Given NetworkManager running on a systemd system
Given NetworkManager cannot handle reconnecting to the dbus daemon
When dbus daemon is restarted
Then NetworkManager is also (automatically) restarted

(*) "dbus daemon" can refer to both dbus-daemon and dbus-broker implementations

(I am not sure, whether BindsTo= can handle restart as described in 2). I don't read that from `man systemd.unit`).

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (NetworkManager bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:6585