tests: add test of systemctl restarting snapd in various ways - #16231
tests: add test of systemctl restarting snapd in various ways#16231olivercalder wants to merge 1 commit into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #16231 +/- ##
==========================================
+ Coverage 78.86% 78.92% +0.05%
==========================================
Files 1403 1396 -7
Lines 196311 196092 -219
Branches 2462 2462
==========================================
- Hits 154829 154766 -63
+ Misses 32190 32039 -151
+ Partials 9292 9287 -5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Wed Jul 22 18:40:51 UTC 2026 Failures:Preparing:
Executing:
Restoring:
Skipped tests from snapd-testing-skipIf you wish to have any of the below tests run in your PR, in your PR description, add 'unskip:' followed by a copy-and-pasted list of the below tests you wish to run (unskip plus test list must be valid yaml)
|
|
Nevermind, some tests failed! For example: https://github.com/canonical/snapd/actions/runs/18980154198/job/54211757242 Let's see if the same thing occurs with the |
|
@olivercalder should this PR be closed or rebased? |
1438c1b to
e509759
Compare
|
Rebased to see if tests are happy |
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
e509759 to
cd6fc24
Compare
|
I rebased, ran this locally, and everything passed on ubuntu-{20,22,24,26}.04-64. So I don't think there's anything interesting to learn here by having this in the test suite. The aforementioned prompting kernel bug only occurs if prompting is actually enabled, which it's not here. So probably not worth adding this test to run everywhere when there should not be issues with restarting snapd. |
There was a potential concern that
fdstorechanges from #16119 could affect snapd restarts.In particular, I had observed that the following was blocking while I was working on #15508:
and anecdotally, the following worked instead:
However, I now believe that was caused by a kernel bug with notification protocol v5, rather than a problem with the
fdstorePR #16119Therefore, I tentatively believe the PR to revert the
fdstorechanges is not necessary: #16228This work is tracked (in part) by https://warthogs.atlassian.net/browse/SNAPDENG-36554