While testing two somerville platforms, I noticed the stress/cpu_stress_ng_test job would hang if the device's suspend feature was not deactivated beforehands. Talking with Jerry, it seems that it's a known issue, so testers always manually deactivate suspend before stress/cpu_stress_ng_test is started.
To reproduce:
1. On a device with suspend activated (Settings > Power > Automatic Suspend), start stress/cpu_stress_ng_test.
2. At the period set in the Automatic Suspend screen, the device tries to suspend.
3. From now on, the CPU stress test seems like it's running, but it will never complete and Checkbox cannot finish the testing session.
Workaround: Make sure Settings > Power > Automatic Suspend is set to OFF.
A solution could be to automatically deactivate suspend before starting this test, and automatically reactivate it after the test is finished, using those commands (see <https://askubuntu.com/a/651437>):
# Deactivate suspend
gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type nothing
gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type nothing
# Reactivate suspend
gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type suspend
gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type suspend
It seems this issue only appear with stress/cpu_stress_ng_test, so it might be possible to just add those commands into the job itself. Otherwise, we could create two new jobs and, using the `depends` flag, make sure stress/cpu_stress_ng_test is sandwiched between them.
I'm not sure how this would work on the server side, though...
I would suggest to use inhibit API[1] to suppress the suspend with the user session, so the test script would not mess around the user settings. The inhibit API should only apply to the machine that are running Desktop.
Since the session is running under the specific Xorg instance. The checkbox should be aware of the DISPLAY environment and pass it to each test job. The dbus-launch command will create yet another user session, which is not something you want to do.
Since the cpustress test can be used on both core and Desktop, I think it's better to have the inhibit as it's own job, and only apply to the desktop environment.
[1] https:/