dbus was stopped during today's jammy update, breaking desktop

dpkg.log from that run

The attached /var/log/apt/term.log does not show anything suspicious

I did not find interesting journalctl, maybe someone else is luckier.

Seems related to https://bugs.launchpad.net/bugs/1961910

This reminds me a lot of https://bugs.launchpad.net/bugs/1871538

Status changed to 'Confirmed' because the bug affects multiple users.

I hit this too - just reported https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1962127 from the associated gnome-shell crash.

Removing the duplicate, because while the other bugs focus on the crashes, this one focuses on dbus stopping. I don't think the crashes matter, fwiw, dbus should not be stopping in the first place, there's no way to gracefully recover from that.

Testing impish to jammy upgrades the graphical session closes just after having the dbus packages updated, same with xubuntu. The different segfaults in graphical components are probably side effects of dbus or xorg going away under their feet

The issue seems to be due to the dbus package

$ cat /var/lib/dpkg/info/dbus.preinst
...
# Automatically added by dh_installsystemd/13.6ubuntu1
if [ -z "${DPKG_ROOT:-}" ] && [ "$1" = upgrade ] && [ -d /run/systemd/system ] ; then
 deb-systemd-invoke stop 'dbus.service' 'dbus.socket' >/dev/null || true
fi
# End automatically added section

shouldn't have that been resolved by https://launchpad.net/ubuntu/+source/dbus/1.12.20-2ubuntu3 ?

Attaching debdiff which I believe should prevent the service from being stopped on upgrade. Test packages are currently building in ppa:waveform/dbus (https://launchpad.net/~waveform/+archive/ubuntu/dbus) but I've already built locally and verified that the offending portion of the preinst maintscript is gone.

Ultimately this is down to a mis-understanding of debhelper's start/restart options (which are unfortunately named, and in my opinion insufficiently documented -- something I'll try and post a patch for upstream):

In Ubuntu (several releases back) we'd altered the dh_installsystemd options for dbus (in d/rules) to "--no-start" intending the service to be activated solely via dbus.socket. Unfortunately, just specifying "--no-start" tells debhelper you don't want the service started, but it still implies that you wish the service to be *restarted* (if it's running) during upgrade. You must *additionally* specify "--no-stop-on-upgrade" (formerly known as "--no-restart-on-upgrade", and not to be confused with "--no-restart-after-upgrade") if you do not want it restarted.

Debian have also (more recently) adjusted their dh_installsystemd options for dbus (for different reasons), so this will also need patching upstream (I'll try and open a bug for this and associate it with this one as it's all the same options affected at the end of the day).

Some additional info:

"dh_installsystemd --no-start" on its own is *not* equivalent to "--no-start --restart-after-upgrade" as one might imagine ("--restart-after-upgrade" is *usually* the dh_installsystemd default). Instead "--no-start" adjusts the restart default to "--no-restart-after-upgrade" (I'm now *fairly* convinced this is actually a bug). Unfortunately "--no-restart-after-upgrade" cannot work with "--no-start" because, whilst the preinst script will always stop the service, the postinst script won't attempt to start it again because "--no-start" is specified.

Even if dh_installsystemd did try to be more intelligent, I'm not convinced this combination can ever work in all circumstances: the postinst maintscript cannot know whether the service was running prior to the preinst script stopping it because the idempotency requirement for maintscripts implies that postinst is not necessarily running immediately after preinst.

In other words, "--no-start --no-restart-after-upgrade" (or "--no-start" on its own which is equivalent) is a broken combination which does not (and probably cannot, at least with the current design) work.

I sponsored this, thanks!

This bug was fixed in the package dbus - 1.12.20-2ubuntu4

---------------
dbus (1.12.20-2ubuntu4) jammy; urgency=medium

  * Prevent dbus from being restarted on upgrade (LP: #1962036)

 -- Dave Jones <email address hidden> Fri, 01 Apr 2022 18:02:54 +0100

With this fix my upgrade Xubuntu 20.04.4 => 22.04 completed.
There was a non-fatal hiccup for Firefox converting to snap.
Reviewing the new instance ...
:D

I wonder whether my problem is this bug 1962036, or something else.
Problem while upgrading impish to jammy: screen showing just
background (no windows), moving/clicking mouse eliciting the
"wait" cursor momentarily.
Fixed by hard reset, boot to "recovery" console, and used:
  dpkg --configure -a
  apt dist-upgrade
  shutdown -r now

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1962036