Project

General

Profile

action #105882

Test using svirt backend fails with auto_review:"Error connecting to VNC server.*localhost.*Connection refused"

Added by okurz 5 months ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Concrete Bugs
Target version:
Start date:
2020-10-30
Due date:
% Done:

0%

Estimated time:
Difficulty:

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


Related issues

Related to openQA Infrastructure - action #106017: [ipmi backend]VNC stalled, no update for 5.38 secondsResolved2022-02-072022-02-22

Related to openQA Project - 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.*":retryResolved2022-02-11

Copied from openQA Project - action #76813: [tools] Test using svirt backend fails with auto_review:"Error connecting to VNC server.*: IO::Socket::INET: connect: Connection refused":retryNew2020-10-30

History

#1 Updated by okurz 5 months 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":retry added

#2 Updated by okurz 5 months ago

  • Related to action #106017: [ipmi backend]VNC stalled, no update for 5.38 seconds added

#3 Updated by okurz 5 months 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

#4 Updated by mkittler 5 months 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.

#5 Updated by okurz 5 months ago

  • Description updated (diff)
  • Category changed from Feature requests to Concrete Bugs
  • 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.

#6 Updated by mkittler 5 months 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.

#7 Updated by mkittler 5 months 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

#8 Updated by okurz 5 months 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 :)

Also available in: Atom PDF