checkbox may resume a session as "root", causing problems with some jobs

[Pierre Equoy]

[Summary]

This issue was identified while running OEM tests on 202010-28292 device, but it happens with other devices as well.

Some jobs fail with unexpected errors. For instance, `audio/2_playback_displayport_*` [1] fails with:

subprocess.CalledProcessError: Command '['pactl', 'info']' returned non-zero exit status 1.
Connection failure: Connection refused
pa_context_connect() failed: Connection refused

It turns out it's because the command `pactl info` is run as root. (try running `sudo pactl info` on your own device and you will have the same problem)

It seems that, when Checkbox automatically resumes a session after rebooting, it resumes the session as root.

I noticed this because if I open another tab in the gnome-terminal window that has been opened by Checkbox, the user is `root`.

[Steps to reproduce]

Run a session that involves an audio job (that calls pactl at some point) *after* a reboot

[Expected outcome]

The jobs run normally and pass

[Actual outcome]

The jobs spit some weird output and/or fail (because they are run as root when they should be run as a normal user)

[Additional info]

Checkbox is used in local mode (not remote)

checkbox-ng: 1.11.0
checkbox-support: 0.48.0
com.canonical.ce:oem: 1.0
certification-client: 0.43.0
plainbox-provider-checkbox: 0.55.0
plainbox-provider-resource-generic: 0.46.0
plainbox-provider-tpm2: 1.14.0

[1] https://certification.canonical.com/hardware/202010-28292/submission/189495/test/87427/result/15223112/

[Sylvain Pineau (sylvain-pineau)]

Let's start by promoting the use of remote which is the easiest way to not face this kind of problem with stuff owned by root after reboot.

Here the culprit is pm_test once again which when done with the last pm iteration restarts checkbox using a command like:

sudo -u <invoking_user> bash ...

So even if checkbox runs as a normal user, being somehow owned by root in the process hierarchy prevents to start pulseaudio commands as expected.

To still run checkbox locally, I'd recommend to switch to power-automated from https://git.launchpad.net/plainbox-provider-checkbox/tree/units/power-management/test-plan.pxu#n72 to replace the use of https://git.launchpad.net/~oem-qa/oem-qa-checkbox/+git/oem-plainbox/tree/units/somerville-graphic.pxu#n19 in somerville test plans since those jobs only perform a single reboot/poweroff.

[StanleyHuang (stanley31)]

The session won't resume after restart the system during the power-automated testing locally. I will file another bug to tracking this issue.

An error message has been noted on syslog as following:
May 6 00:22:36 u-ThinkStation-P520c gnome-session[1731]: gnome-session-binary[1731]: WARNING: Could not parse desktop file com.canonical:checkbox-cli.desktop or it references a not found TryExec binary
May 6 00:22:36 u-ThinkStation-P520c gnome-session-binary[1731]: WARNING: Could not parse desktop file com.canonical:checkbox-cli.desktop or it references a not found TryExec binary

And the autostart configuration as following:
[Desktop Entry]
Categories=System
Comment=Automatically resume the testing session
Exec='/usr/bin/checkbox-cli launcher --resume session_title-2021-05-06T05.25.02';$SHELL
GenericName=Resume Testing Session
Name=Resume Testing Session
StartupNotify=false
Terminal=true
Type=Application
Version=1.0

It seems the contents in Exec field is not valid on 20.04, because of it works after I changed the contents of Exec field to following string.
Exec=/usr/bin/checkbox-cli launcher --resume session_title-2021-05-06T05.25.02

[Maksim Beliaev (beliaev-maksim)]

Bug was migrated to GitHub: https://github.com/canonical/checkbox/issues/77.
Bug is no more monitored here.