Apparmor profile not generated correctly after failed snap refresh
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
snapd |
Fix Committed
|
Critical
|
Unassigned |
Bug Description
After one or more cycles of a snap refresh failing, the snap refresh eventually succeeded but was left in a non-functional state because the apparmor profile was not correctly generated.
---
The snap was failing to refresh due to a bug in the post-refresh hook, and was getting rolled back. This happened 4 times each day on the scheduled refresh interval. As far as I know, the snap was correctly rolled back each time.
A fix was pushed and then the snap refresh succeeded, leaving the latest version of the snap installed. However the app armor profile (/writable/
```
@{SNAP_
```
Was set to the previous revision (which had been repeatedly rolled-back), and not the currently installed revision. This was causing all access to the installed snaps filesystem to be blocked by apparmor.
We saw this on about 10% of our deployed devices, which points at some kind of non-deterministic issue.
The issue, when detected, can be manually resolved by disabling and then enabling the snap, which forces the regeneration of the apparmor profile.
---
In the debug output uploaded, "results.log" the failing snap was "everactive-
```
13T19:09:32Z" level=panic msg="Error opening database: open /var/snap/
```
Changed in snapd: | |
importance: | Undecided → High |
status: | New → Confirmed |
Changed in snapd: | |
importance: | High → Critical |
We have seen this same issue happen again since this bug was filed. It actually does not appear to be related to the snap refresh failing before it succeeds. That is, we have seen the apparmor profile fail to get updated after only one successful snap refresh to a newer revision.
Is there any further debugging information, or logs we can get that may help us understand the root of the issue?
Thank you!!