Merge lp:~mvo/snappy/snappy-lp1460152-workaround into lp:~snappy-dev/snappy/snappy-moved-to-github
| Status: | Work in progress |
|---|---|
| Proposed branch: | lp:~mvo/snappy/snappy-lp1460152-workaround |
| Merge into: | lp:~snappy-dev/snappy/snappy-moved-to-github |
| Diff against target: |
157 lines (+78/-6) 5 files modified
helpers/helpers.go (+17/-0) helpers/helpers_test.go (+11/-1) snappy/dirs.go (+4/-0) snappy/systemimage.go (+16/-5) snappy/systemimage_test.go (+30/-0) |
| To merge this branch: | bzr merge lp:~mvo/snappy/snappy-lp1460152-workaround |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Ricardo Salveti (community) | 2015-06-04 | Needs Information on 2015-06-04 | |
|
Review via email:
|
|||
Commit Message
This branch adds a workaround for LP: #1460152 to prevent that the
apparmor profile and cache get out of sync.
Description of the Change
This branch adds a workaround for LP: #1460152 to prevent that the
apparmor profile and cache get out of sync.
| Sergio Schvezov (sergiusens) wrote : | # |
| Ricardo Salveti (rsalveti) wrote : | # |
Wouldn't this only be triggered after doing a second update? The major problem we have is that we're currently over a stable/older image, and we want to update to edge, and make sure that the new cache is not broken on the next reboot, but we're still updating to edge using the tools available at stable (not using the extra logic you added here).
So the workaround would need to be either something triggered by the update process coming from stable, or something done as part of the first boot after updating the image.
| Sergio Schvezov (sergiusens) wrote : | # |
Tears aside ;-) this is lacking some sort of systemd unit to trigger apparmor cache cleaning on boot (we can probably leverage the one apparmor has itself).
| Michael Vogt (mvo) wrote : | # |
@Ricardo: Indeed you are right :/ Sorry for overlooking this, at some point we need to add the ability for the upgrader to upgrade itself. So the best way seems to be going a systemd unit route (as Sergio suggested).
@Sergio: I pushed an alternative solution based on systemd to http://
The full diff is here:
https:/
If the approach looks good this needs to go to the ppa and get a real-world test (i.e. 15.04 stable->edge upgrade). Please keep me updated via mail or telegram as I won't be on irc today.
Unmerged revisions
- 486. By Michael Vogt on 2015-06-04
-
Remove /etc/apparmor.
d/cache/ * on upgrade to workaround lp1460152 This works around the issue that the way apparmor creates the cache
is based on the mtime of the profile. So if the mtime of the profile
is older than the mtime of the cache file the cache is not re-generated.This is a problem because:
- boot stable, /etc/apparmor.d/cache/ usr.bin. ubuntu- core-launcher is mtime of now because we generate the cache on boot
- upgrade to edge, /etc/apparmor.d/usr.bin. ubuntu- core-launcher is updated and has the mtime of T (yesterday) when the file was put into the package
- on the next reboot the apparmor_parser compares the mtime of the cache/usr.bin.ubuntu- core-launcher (very very recent) with the mtime of the souce usr.bin. ubuntu- core-launcher (much older)
-> cache does is *not* re-generateThe real fix is IMO that apparmor adds the mtime of the profile into
the header of the cache file (or makes the mtime of the cache file)
the mtime of the profile and re-generated if they get out of sync
(instead of checking for newer).


I linked the bug, we can add a task for a proper implementation.