/usr/lib/ubuntu-advantage/esm_cache.py:ModuleNotFoundError:/usr/lib/ubuntu-advantage/esm_cache.py@5:/usr/lib/python3/dist-packages/uaclient/apt.py@13:/usr/lib/python3/dist-packages/uaclient/event_logger.py@14
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ubuntu-advantage-tools (Ubuntu) |
Fix Released
|
Undecided
|
Renan Rodrigo | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Undecided
|
Unassigned | ||
Jammy |
Fix Released
|
Undecided
|
Unassigned | ||
Kinetic |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
If python3 was able to import uaclient but unable to import yaml for some reason, pro client processes would crash.
ubuntu-
In the case where python3-yaml is installed properly, but the user's python environment is set up in such a way that it isn't seen by a normal `import yaml`, then we can mitigate the issue. We will log an error and exit when yaml is not found, avoiding a crash and autoamatic error reports.
[Test Case]
In a container, set up a contrived python environment where it can see uaclient and apt but not yaml:
```
apt update
apt install python3-venv
python3 -m venv env
source ./env/bin/activate
ln -s /usr/lib/
ln -s /usr/lib/
ln -s /usr/lib/
python3 /usr/lib/
systemctl start esm-cache.service
```
(Note that the python version will be different on different Ubuntu releases)
Before the fix, that last commands will fail because u-a-t cannot import yaml.
After the fix, it will log an error, return 1, and no crash will be present in /var/crash related to this.
[Regression Potential]
The fix relies on importing yaml functionality from uaclient.yaml - if in any code we import directly from yaml, it will bypass this fix and fail in the same scenario as this bug does. We need to pay attention to not import yaml directly in any other module.
The fix involves re-exporting the yaml functions, if we missed an export that another piece of code relies on, then that would cause an unhandled exception.
[Discussion]
Until recently our position had been: non-standard python install -> unsupported. This fix is deals with the error in a best-effort implementation to avoid crashes and automatic reports from errors.ubuntu.com, which can block phasing for no reason.
[Original Description]
The Ubuntu Error Tracker has been receiving reports about a problem regarding ubuntu-
If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://
Changed in ubuntu-advantage-tools (Ubuntu): | |
assignee: | nobody → Grant Orndorff (orndorffgrant) |
Changed in ubuntu-advantage-tools (Ubuntu): | |
assignee: | Grant Orndorff (orndorffgrant) → Renan Rodrigo (renanrodrigo) |
Changed in ubuntu-advantage-tools (Ubuntu): | |
status: | New → In Progress |
description: | updated |
description: | updated |
AFAICS this is odd at the first look.
We have the error being: rror: No module named 'yaml'
ModuleNotFoundE
But OTOH clearly yaml is installed and the dependency is correct.
$ apt-cache show ubuntu- advantage- tools advantage- tools /bugs.launchpad .net/ubuntu/ +filebug
Package: ubuntu-
Architecture: amd64
Version: 27.13.5~22.04.1
Priority: important
Section: misc
Origin: Ubuntu
Maintainer: Ubuntu Developers <email address hidden>
Bugs: https:/
Installed-Size: 877
Depends: debconf (>= 0.5) | debconf-2.0, python3-yaml ...
Yet on a second look this might be related to an upgrade scenario.
I've found all that are affected by this to be of the following scenario:
Examples on 22.04: /errors. ubuntu. com/oops/ cdd35f74- aae8-11ed- 9e26-fa163e9934 15 /errors. ubuntu. com/oops/ ac520bde- aae8-11ed- 9e26-fa163e9934 15 /errors. ubuntu. com/oops/ defe9d0e- abd1-11ed- 9e34-fa163e9934 15
https:/
https:/
https:/
1. installed Focal (not too long ago)
2. upgraded to Jammy just now
3. the crash shows
3.1 the UAT version of Jammy (packages got upgraded, so most likely did python3-yaml)
3.2 the python3.8 of focal
I wonder (and this is a theory only, might be very wrong) if we have a long running process to update the cache still running with python3.8 of focal, but when it reaches out to do work after the upgrade it will try to import yaml and the installed version is only for the py3.10 of jammy and no more for the 3.8 interpreter of focal which this still runs in.
And if that would be true, should we stop and restart those background jobs on upgrade (like services are restarted, unless we already do that - as I said just a theory).