xnox and I debugged this together, and it seems like the upload of 234 in Debian switched to Meson, and there was a bug introduced here where KillUserProcesses was set back to `yes' instead of `no' as it's meant to be. To reboot the machine, autopkgtest runs `sh -c (sleep 3; reboot) &' over SSH. When we background this and then end the SSH connection - and logind session - systemd kills the sleep and the reboot is never run, so we see a system that has come up but never gone down.
I found this by entering a machine in the bad state and looking at the journal. In future I suggest that systemd's autopkgtests output the journal to their log so that this would be debuggable without admin access next time. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1708051 Title: v234 seems to fail to reboot 5 times in a row on s390x, and crashes amd64/i386 instances Status in systemd package in Ubuntu: New Bug description: ppc64el is fine. Given that everything is fixed to start containers and vms non- degraded, let's enforce that we boot not degraded. Also network online timeout is 30s, thus it makes no sense to only give the boot 10s. Especially since machines can be overcommitted with capacity. update: tests were improved somewhat, to be more deterministic and always wait for the boot to fully finish before rebooting. On the infrastructure - all but i386/amd64 pass. But locally it is not reproducible. It almost feels like openstack-nova-autopkgtest-reboot- marker integration is broken; or systemd fails to reboot in scalingstack. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1708051/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
