action #105882
closedTest using svirt backend fails with auto_review:"Error connecting to VNC server.*localhost.*Connection refused"
Description
Motivation¶
See #76813 about trying to connect to remote machines but there are also cases where we try to connect to localhost and fail. This seems like something that we should be able to improve within os-autoinst itself.
Steps to reproduce¶
Find jobs referencing this ticket with the help of
https://raw.githubusercontent.com/os-autoinst/scripts/master/openqa-query-for-job-label ,
call openqa-query-for-job-label poo#XXX
Updated by okurz about 2 years ago
- Copied from action #76813: [tools] Test using svirt backend fails with auto_review:"Error connecting to VNC server.*: IO::Socket::INET: connect: Connection refused" added
Updated by okurz about 2 years ago
- Related to action #106017: [ipmi backend]VNC stalled, no update for 5.38 seconds added
Updated by okurz about 2 years ago
- Related to action #106654: [ipmi][openqa][vnc] Massive test run failures with 'IO::Socket::INET: connect: Connection refused' due to "Use of uninitialized value.*connect_timeout in addition.*consoles/VNC.pm line 13.*":retry added
Updated by mkittler about 2 years ago
- Status changed from New to Feedback
- Assignee set to mkittler
The problem is most likely the VNC stall detection which might cause re-connects but that's not possible within our Xvnc setup. This PR should fix it: https://github.com/os-autoinst/os-autoinst/pull/1949
Note that the "related ticket" #106654 is due to the VNC connect timeout being undefined which is a different cause than what this ticket is likely about.
Updated by okurz about 2 years ago
- Description updated (diff)
- Category changed from Feature requests to Regressions/Crashes
- Target version changed from future to Ready
Ok, let's regard this ticket as "Concrete Bugs" then due to the regression. We should still aim for improving the error reporting so that in similar cases it is more clear to users what to do.
Updated by mkittler about 2 years ago
- Description updated (diff)
We should still aim for improving the error reporting so that in similar cases it is more clear to users what to do.
It is hard to tell what's causing the problem from just looking at the error message. I'm not sure how we'd automatically derive a suggestion to the user especially since the issues we've found here (interfering VNC stall detection, timeout passed incorrectly) were really bugs on our side. We could only provide what kind of VNC server was supposed to respond as additional context (e.g. QEMU's VNC server, Xvnc, …) which would also help ourselves on the next ticket.
Updated by mkittler about 2 years ago
The PR fixing the issue with Xvnc and the VNC stall detection has been merged.
I created another PR for the idea mentioned in the previous comment: https://github.com/os-autoinst/os-autoinst/pull/1955
Updated by okurz about 2 years ago
- Status changed from Feedback to Resolved
https://github.com/os-autoinst/os-autoinst/pull/1955 merged. I guess that already helps a bit. I am sure users will still be confused who should do what then in such case but better than before so ok to resolve :)