MAAS on its own does not deploy a stopped dbus service in my testing; it only happens when juju is involved. I've isolated this to "service networking restart" done by juju using cloud-init userdata. I've updated the description. I think a fix for juju would be straightforward: don't do that; use more targeted "ifdown" and "ifup" as required instead. Note that the "ifdown" should be called before changing /etc/network/interfaces.
However, adding a dbus task, as it is arguable that dbus should not die in this case, and certainly not silently. A "Won't Fix" resolution for dbus dying might be acceptable, though, if it is not expected to survive all network interfaces being deconfigured. But a log message explaining would be nice.
MAAS on its own does not deploy a stopped dbus service in my testing; it only happens when juju is involved. I've isolated this to "service networking restart" done by juju using cloud-init userdata. I've updated the description. I think a fix for juju would be straightforward: don't do that; use more targeted "ifdown" and "ifup" as required instead. Note that the "ifdown" should be called before changing /etc/network/ interfaces.
However, adding a dbus task, as it is arguable that dbus should not die in this case, and certainly not silently. A "Won't Fix" resolution for dbus dying might be acceptable, though, if it is not expected to survive all network interfaces being deconfigured. But a log message explaining would be nice.