* interfaces/apparmor: add permissions for per-snap directory on ubuntu-save path
* overlord/snapstate: implement support for storing data onto ubuntu-save partition on a per-snap basis
* tests/nested/core/save-data: fix shellcheck warning
* many: a bit of code cleanup
* tests/nested/core/save-data: cleanup spread test
* many: fix unit tests that were failing, add additional unit test for new handlers
* tests/main/snap-env: fix spread test after adding a new ENV variable
* overlord/snapstate: minor cleanup
* overlord/snapstate: review feedback
remove the ubuntu-save task, move some of the functionality into the backend, add unit tests
* multiple: more changes, fix unit tests
* overlord/snapstate: additional unit tests
* tests: remove check that is no longer the case for non core platforms
Snapd installs bash completion files from snaps in
`/usr/share/bash-completion/completions` which in some distributions
is a read-only filesystem.
Instead of installing them in `/usr` we can install them within
`/var/lib/snapd` which should always be writable.
Because `/var/lib/snapd/desktop` is already in `XDG_DATA_DIRS`, we can
save the files there.
Because bash-completion 2.1 and prior do not support `XDG_DATA_DIRS`,
on older distributions, the legacy path
`/usr/share/bash-completion/completions` will still be used.
This reverts commit d5eb40d189.
PR #11003 unfortunately introduced a regression on systems where the memory
cgroup was disabled because now servicestate.AllQuotas would return an error,
but we need to be able to access at least the quota group information in the
state in order to compute what options to generate services with in a few
places:
* in the ensure loop of the servicestate manager (runs all the time)
* in link-snap tasks (for snap installs/refreshes)
* in config tasks (for specifically the vitality-rank config setting)
* in discard-snap tasks (for snap removes)
So when the memory cgroup is disabled, all of the above things fail, including
catastrophically not being able to update the snapd snap (since snap refreshes
are now also broken), meaning that a user's device could not be fixed unless
they first re-enable the memory cgroup.
This will be un-reverted when we have added sufficient tests to demonstrate
that this memory cgroup check can be done in such a way without breaking this
functionality.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* added check for memory group statud (enabled/disabled) before any quota commands for bug: 1945370
* added check for memory group statud (enabled/disabled) before any quota commands for bug: 1945370
* moved the memory cgroup status check to servicestate
* removed memory cgroup check on the client
* merge error
* Update cmd/snap/cmd_quota.go
Co-authored-by: Maciej Borzecki <maciek.borzecki@gmail.com>
* Update overlord/servicestate/quota_control.go
Co-authored-by: Maciej Borzecki <maciek.borzecki@gmail.com>
* Update overlord/servicestate/quota_control.go
Co-authored-by: Maciej Borzecki <maciek.borzecki@gmail.com>
* updated the error flow structure
* fixed merge issue
* updated message for invalid configuration size and removed indentation
* Update overlord/servicestate/quota_control.go
Co-authored-by: Ian Johnson <person.uwsome@gmail.com>
* Update overlord/servicestate/quota_control.go
Co-authored-by: Miguel Pires <miguelpires94@gmail.com>
* moved cgroups file to dirs & made changes to the PR based on reviews
* added default file to make sure other tests using from global root don't fail
* updated the malformed cgroup test to have only 3 fields and minor changes
* corrected the quota control group size
* Update overlord/servicestate/quota_control.go
Co-authored-by: Maciej Borzecki <maciek.borzecki@gmail.com>
* Apply suggestions from code review
Co-authored-by: Maciej Borzecki <maciek.borzecki@gmail.com>
* removed unused import
* added test case for missing memory line
* removed the extra import coming from the use of check prefix
* updated variable names in test to remove _ prefix
* merged the latest master
Co-authored-by: Maciej Borzecki <maciek.borzecki@gmail.com>
Co-authored-by: Ian Johnson <person.uwsome@gmail.com>
Co-authored-by: Miguel Pires <miguelpires94@gmail.com>
* devicestate: ensure permissions of /var/lib/snapd/void are correct
During the testflinger testing I saw some failures in the
`tests/main/cwd` test where the permissions of the
`/var/lib/snapd/void` directory are incorrect. On systems that
use packaging tools we force the permissions to be 0111 on each
refresh (see `debian/snapd.postinst`). However no such mechanism
exists on core devices. So if for some reason the permissions get
corrupted they never get fixed.
This commit adds code that ensures the permissions are fixed
automatically here too.
There can be situations where there exist two snapd processes in the
system: that's the case when one of them is invoked as a subprocess by
the snap-failure systemd unit (which runs cmd/snap-failure/cmd_snap.go),
which we refer to as the "ephimeral snapd", and the other one is the
new, repaired snapd which is started by the ephimeral one. When this
happens, we do not want both of these processes to operate on the
snapstate at the same time; therefore, create a file-based lock to make
the accesses mutually exclusive.
A file-based lock will cause the second process to block and wait until
the lock is released (which can happen either as a result of an explicit
release operation, or at the termination of the process holding it). The
process starting snapd therefore needs to invoke the "systemctl start
snapd.service" command in non-blocking mode, or it would get itself
blocked, too.
Fixes: https://bugs.launchpad.net/snapd/+bug/1952404
