Stop unattended upgrades restarting xrdp under a live session

FixKlusterServices
Shipped
August 27, 2026 at 6:04 PM UTC
Author
Kamo
Commit
4d38d23

The black screen was apt. apt-daily-upgrade.service upgraded xrdp at 06:49 UTC on 2026-08-27 and restarted it while a desktop from 2026-08-25 was running. xrdp-sesman keeps its session registry in MEMORY, so the restart made it forget that session while the Xorg process kept going. The next login could not be matched to it and got a SECOND display — and the second one is black, because Plasma is single-instance per user: both displays share one D-Bus session bus, so the second plasmashell collides with the first and dies. Found three orphaned sesman processes and two X servers on the machine, :10 with a full desktop and :11 with startplasma and nothing else. kamo-xrdp-reset.sh already documents this exact failure (observed 2026-08-16 with four displays), but it only runs when WE restart xrdp. Nothing covered a package upgrade doing it on a timer, at an hour nobody is watching. Two layers, because "we removed the one job that did this" is weaker than "a restart cannot leave the machine unreachable": kamo-no-auto-updates.sh masks the apt-daily timers and services and zeroes the APT::Periodic settings. This is a workstation people connect INTO; nothing may restart the thing they connect through unattended. Updates become deliberate. kamo-xrdp-reap-orphans.sh runs as ExecStartPre on xrdp-sesman, so whatever restarts it, sessions it can no longer be managing are cleared and the next login gets a clean desktop instead of a black one. Losing a disconnected session is the right trade: it was already unreachable the moment sesman forgot it — the only question was whether the user found out via a black screen. Applied to the running VM and verified after a reboot: 1 sesman (was 3), 0 stale X servers, reaper wired, all three apt units masked, 57 packages upgraded. A real session opened through the public gateway now brings up kwin_x11 and plasmashell on a single display. Also drops the canary's TCP probe of the VM's RDP port. The VMI readiness probe already covers :3389 (KamoDesktopRdpEndpointEmpty), so it added no coverage — and it was not free: every bare connect makes xrdp log six ERROR lines about a failed connection sequence, and that noise buried the real errors while diagnosing this outage. A monitor that makes the logs harder to read takes away more than it gives.

All changes

Like what you see shipping?

Every one of these updates lands in your workspace automatically. Start free and watch it grow week after week.

Start Free ForeverView Pricing