Thanks ddstreet, I agree 918e6f1c0151429f5095355f4f3f74f16e79724a could be related as well, but unfortunately that commit produced quite some fall-out.
Nevertheless, I've prepared a new systemd build in my PPA and the "core18_20211118_amd64.snap" at https://people.ubuntu.com/~slyon/uc18/ cherry-picking the changes from https://github.com/systemd/systemd/pull/8675 (incl. 918e6f1c) As I said, there are quite some other PRs related to this, in order to clean-up after it https://github.com/systemd/systemd/pull/8798 https://github.com/systemd/systemd/pull/9200 https://github.com/systemd/systemd/pull/9229 https://github.com/systemd/systemd/pull/9366 In total that should be approx. 1000 changed LOC... So I'm not sure how suitable this is for SRU. But let's first give this newest build a try and check if the initial commit/PR changes anything wrt to our core problem here, if so we can into the details of those backports (and hopefully skip manny commits of those). -- 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/1949089 Title: systemd randomly fails to activate mount units in Ubuntu Core 18 Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Bug description: Since a month or so, we've been seeing random failures in our snapd spread tests where systemd could not start the mount unit associated with a snap because of a failed dependency. The issue is described in the comments to PR https://github.com/snapcore/snapd/pull/10935, but I'll summarize it here. When starting a snap, snapd creates a mount unit to mount the snap's squashfs (the template is https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205). The snapd asks systemd to reload the configuration, and starts the mount unit. The failure we've observed is that sometimes systemd decides to stop our mount unit (search for "Unmounting Mount unit for test-snapd-svc- flip-flop" in the attached log), and then tries to reactivate it again, and at that point it fails. When I asked for help, Lukas pointed out that the latest update contains a patch that is related to reload handling and mount units: http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz (the patch itself is better visible at https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656). When looking at the systemd git log, though, I noticed another patch that was applied shortly after this one, which also seems related but was not backported: https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0 Since the stopping of our mount unit happens immediately after a systemd reload, it actually seems very likely that the inclusion of f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what causes our woes (though, indeed, the issue is not reliably reproducible, so we cannot be sure). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
