sosreport: Add fallback error message, fix testInsightsClient failure on rhel4edge

[martinpitt]

If sos report fails, we can get an empty message in error. That will lead to not showing the error in the dialog at all (as it's falsy), even if errorDetail was set. Fix that by adding a generic fallback title.

Also log the full error for easier debugging.

---

I noticed this while investigating the current sos rawhide failure. This looks really unfriendly -- you click "Report", the dialog flickers and nothing happens. Now it shows the error properly:

[martinpitt]

rhel-8-9 does not seem to pick up the mock /usr/local/bin/sos. That's because sos lives in /usr/sbin, and it has a different $PATH preference. Also, the C bridge has a different error.

Fixed both.

[marusak]

ah nice, thanks! My first thought when I checked screenshots in the naughty was, why is there no error in the dialog

[martinpitt]

This failure looks unrelated, but repeats ND@6 did not run any SOS related test. Retrying to compare.

I ran the test locally by itself four times, and they all passed. I also ran the exact same list of ND@6 tests locally:

TEST_OS=rhel4edge test/common/run-tests --no-retry-fail --test-dir test/verify/ TestAccounts.testGroupCreate TestConnection.testHeadRequest TestCurrentMetrics.testMemory TestMenu.testDarkThemeSwitcher TestNondestructiveExample.testOne TestPackages.testBasic TestRoles.testBasic TestServices.testBasic TestServices.testRelationshipsUser TestServices.testServicesThemeConsistency TestServices.testTransientUnits TestSystemInfo.testInsightsStatus

These also passed. But on CI it failed again.

I added two commits which may help.

It also happens on other PRs, so this is unrelated. It may have come with cockpit-project/bots#5015 (yesterday's image refresh), but the test succeeded there.

This debug log shows that there are no insights related processes, and fuser didn't find anything either.

This log brings some insights (haha):

8556 /bin/sh -c #! /bin/sh  # Poll until /var/lib/insights/insights-details.json is 5 minutes # older than /etc/insights-client/.lastupload, then exit.  # Calling "insights-details --check-results" only returns results # corresponding to the most recent upload some time after the upload, # but we don't know when exactly.  We assume that it will not take # more than 5 minutes.  However, we also want the results as soon as # they are available so we poll a couple of time before the 5 minutes # are up.  # We poll fast for the first minute, and then slow down.  Also, there # is a absolute limit on how often we poll, in case something is wrong # with the time stamps (such as .lastupload being from 5 years in # future).  set -eu  details_out_of_date () {     if ! [ -f /etc/insights-client/.lastupload ]; then         return 1     fi     if ! [ -f /var/lib/insights/insights-details.json ]; then         return 0     fi     last_upload=$(stat -c "%Y" /etc/insights-client/.lastupload)     details=$(stat -c "%Y" /var/lib/insights/insights-details.json)     [ $details -lt $(expr $last_upload + 300) ] }  tries=0 while [ $tries -lt 20 ] && details_out_of_date; do     insights-client --check-results     if [ $tries -lt 5 ]; then         sleep 10     else         sleep 60     fi     tries=$(expr $tries + 1) done  --

I can't find the source of this anywhere. So one more round..

This reproduces reliably on a CI machine. I don't yet know what the difference is between that and local tasks toolbox.

[marusak]

Thanks! Just one comment but not a good reason to block this :)

[marusak]

Danke!