mirror of
https://github.com/token2/snapd.git
synced 2026-03-13 11:15:47 -07:00
1aee1f0b80
* data/systemd/snapd.service: use RestartMode=direct
Systemd 254 introduced a new behavior, when the a service during automatic
restart goes through the failed/inactive state such that OnFailure/OnSuccess
dependencies get triggered. In previous releases those dependencies would only
be triggered when the unit has failed to active (or finished). This results in
an unexpected behavior when the snapd.failure.service is invoked at runtime
without an ongoing snapd refresh. Snap-failure starts the snapd binary from the
previous revision of the snapd snap, but since there was no snap change in
progress, snapd just continues to run however with the parent process being
snap-failure instead of systemd. Setting RestartMode=direct brings back the old
behavior when service was automatically restarted.
See e67129e5e4/NEWS (L1796-L1801)
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* tests/core/snapd-failover: verify snapd process cgroup (and hence systemd unit)
Make sure that snapd process is running within the context of the snapd.service
unit.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* tests/core/snapd-failover: update log match to catch the right event
Update the test to look for a log that actually matches what is logged in the
system. Specifically `Starting...` is logged when the unit gets activated, while
`Started..` when the unit completed activation. In case of one-shot units, the
'starting' log comes first, while 'started' is logged after the unit has become
active.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* tests/core/snapd-failover: encode systemd unit failure behavior in the test
When running the test on UC6, verify that snapd.failure.service was indeed
triggered in the simplest scenario.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
---------
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>