This commit replaces the use of "sanity" with more inclusive
naming.
When `sanity` is used in a more general sense either `validity`
or `quick` is used.
had to make the comment in wrappers/services_test.go a one-liner
otherwise half of it is lost
last set of files needing changing (as per current master)
The errtracker checks if whopsie is enabled. This check is not
properly mocked so this fails on systems where this is disabled.
This commit fixes the missing mock.
introduce a new package snapdenv to present the common env options
for snapd components
start with snadpenv.Testing exposing SNAPPY_TESTING
it doesn't make sense for *util packages to use snapdenv directly,
as a consequence move (Set)UserAgent from httputil to snapdenv
Before this there was an Uname implementation in arch and one in
release (the implementation is slightly tricky because
syscall.Utsname's internals are arch-dependent). This drops both in
favour of a new one in osutil, in order to keep syscalls limited to
this package as much as possible.
* errtracker: do not send duplicated reports
This will add a 7 day history for the error tracker. It will not
send the same report over and over again but instead skip reports
that were already send.
Reviews asked for locking and this means we need something better
than the hand implmented DB. Switch to boltdb because we already
use it for the advisor interface.
The whoopsie upstream asked us to check for whoopsie.service instead
of reading /etc/whoopsie when checking if whoopsie is enabled or not.
This PR implements this check by doing what `whoopsie-preferences`
is doing when checking if whoopsie is enabled or not.
* errtracker: add more fields to aid debugging
* errtracker: ship more of PATH
* errtracker: further tweak new data collectors (thanks zyga, mvo)
* errtracker: address nitpicks from zyga :-)
We must support the settings of the user about sending problem
reports. This is implemented on Ubuntu via the /etc/whoopsie
configuration and that config is controllable via the
gnome-control-center.
We should probably also have our own internal configuration
(snapd.problem_reports={true,false}?). But that will be a
followup PR.
The SNAP_DID_REEXEC environment caused two bugs already, one with
classic confinement snapd and one in the error tracker. Instead
of relying on this we inspect the /proc/self/exe now to see if
snapd did reexec or not.
Re-execution affects which internal tools and which snapd is used.
while the current error report shows us hashes of both distribution
and core snapd we always need to guess which one is being used
by inspecting the version string. This makes it more obvious.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
This patch extends the error report with information about the used
snap-confine apparmor profile (as expressed by the text of the file) as
well as hint of partial dpkg update.
Partial or failed updates can leave the old (previous) apparmor profile
of snap-confine around (since it is tagged as a conffile) and
subsequently cause any snap execution to fail with access to
"/run/snapd/lock" directory.
To test the theory we will now measure the hashes of the current and any
.dpkg-new versions of the apparmor profile of snap-confine and attach
them to the report.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
