* 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>
Allow all service's control group processes to send notifications via
sd_notify. This is necesssary to prevent log flooding with systemd
warnings like:
Apr 05 14:36:55 qemuname systemd[1]: snapd.service: Got notification
message from PID 1002, but reception only permitted for main PID 917
This warnings are happening due to a change in systemd 254 that makes
all systemd programs (systemctl, udevadm, systemd-detect-virt, etc.)
send EXIT_STATUS notifications when exiting.
Fixes LP#2060310.
Make sure that /snap/snapd/current is set before executing any binary
from snapd snap.
We will rely on `/snap/snapd/current/lib64/ld-linux.so.2` (varies
depending on architecture) being available to execute binaries from
the snap. So the symlink has to be set before we restart services.
In case of re-execution, snapd snap has to be
mounted. apparmor.service has a dependency to local-fs.target which is
enough in theory. But in case this dependency dispappears, it is
better to have an explicit dependency to snapd.mount.target in the
unit.
`snapd.mounts-pre.target` will be before any mount unit,
`snapd.mounts.target`. Now we can schedule before or after mounts
without needing to modify the mount units.
We also install those mounts to `snapd.mounts.target` so that we can
make snapd.service for example, "want" all mounts.
The implementation of these services is not yet ready, but in order to
be able to deliver it in a snap package, we need to have at least the
service files installed on the system by the distribution package.
These stubs just reexecute the binaries from the snap.
* tests: add spread test for reexec of prompt services
* packaging: update distros for prompt services
Ship them in Debian and Ubuntu, remove them elsewhere.
* cmd: update error message with unimplemented prompt services
* tests: do not disable prompt-reexec tests in UC
* many: disable prompting for 14.04
The kernel changes will most likely not land there.
* many: install prompt services for Ubuntu Core
* tests: exclude UC16 from reexec-prompt test
The services are installed, but disabled; enabling them is not trivial
and not worth the effort, since prompting will most likely not be
backported there.
* wrappers/core18: don't fail if the prompt service is missing in snapd
This fixes a spread failure in the tests/core/snapd-refresh-vs-services
test, where we install an old version of snapd (2.49) which does not
have the Prompt service.
* tests: fix typo in comment
Thanks @pedronis.
* cmd: add license header
Thanks @Meulengracht
During boot, the initial transaction may contain both snapd.socket and
snapd.service at the same time. In such cases, snapd.service should be
started strictly after snapd.socket (After+Requires), instead of just
simultaniously with it (Requires alone).
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Make the recovery chooser trigger service depend on /dev/input being non-empty.
This will make systemd skip the service when there are no input devices.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
Add RequiresMountsFor= for the two directories snapd.apparmor.service
actually depends on, the location of the profiles and the location of
the cache.
This was always the case, but it slipped below our radar. This is now
relevant due to experimental ZFS support available in Ubuntu 20.04,
which puts /var/lib on a separate mount point that is not available on
early boot.
Signed-off-by: Zygmunt Krynicki <me@zygoon.pl>
While the code may have references to "snappy" we have long ago
not exposed that name. Fix the service description so that the
"Snappy" reference is not seen on system startup nor shutdown.
Signed-off-by: Sergio Schvezov <sergio.schvezov@canonical.com>
This specifically will cause snapd.failure to kick in if 2 broken snapd's are
installed without a reboot or explicitly stopping the snapd.failure service so
that on the second time, snapd.failure will actually be started.
Because of this, it's no longer sufficient to check to see if the snapd.failure
service is active after a broken snapd is installed, we have to look at the logs
to see that it was actually activated/started more times after the broken snapd
was installed than before.
Also since it's always basically inactive, remove the restore section since
there's no point to stopping it now as it will always be inactive essentially.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
