This patch removes the snap.mount (or var-lib-snapd-snap.mount) unit
and replaces it with a systemd generator that does creates such unit
dynamically at runtime, on early boot, when the system is running
without mount event sharing on the root filesystem.
This fixes a bug where if packaging ships the snap.mount unit and the
unit is stopped (even if it is not started) it would stop all the snap
mount units on the system, resulting in broken snaps.
Since the mount unit is no longer known to packaging it will not be
automatically stopped/started by generated maintainer scripts and thus
avoid the issue.
polkit: do not shadow dbus errors, avoid panic in case of errors
With the current code, when the dbus call fails with an error we will shadow it
with our own error. In the process of doing so, we try to access a map in
authResult that is uninitialized, accessing a key will cause a panic.
Signed-off-by: Maciej Borzecki <email address hidden>
configstate: when disable "ssh" we must disable the "sshd" service
When `snap set core service.ssh.disable=true` is run we must disable
the sshd.service instead of the ssh.service. The ssh.service is
an alias for sshd, but if ssh.service is disabled we create a
"mask" file on /etc/systemd/ssh.service. But we need a mask file
for "sshd.service" because the "sshd.service" file is also in the
core snap and the "writable-path" magic will bring it back after
a reboot.
We used to have an emergency timer that would run a forced refresh once
a week to ensure that if something is wrong with our refresh schedule
implementation we have a way out.
We don't need this anymore because:
- we have the monthly schedule now so weekly does not fit anymore
- we have repairs for emergencies which are on their own timer
- our internal refresh got quite a bit of testing since we introduced it
This should be cherry-picked back to 2.31 and 2.32.