Project

General

Profile

Actions

action #105882

closed

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

Added by okurz over 2 years ago. Updated over 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Regressions/Crashes
Target version:
Start date:
2020-10-30
Due date:
% Done:

0%

Estimated time:

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 3 (1 open2 closed)

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

Actions
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.*":retryResolvedokurz2022-02-11

Actions
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"New2020-10-30

Actions
Actions #1

Updated by okurz over 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
Actions #2

Updated by okurz over 2 years ago

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

Updated by okurz over 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
Actions #4

Updated by mkittler over 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.

Actions #5

Updated by okurz over 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.

Actions #6

Updated by mkittler over 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.

Actions #7

Updated by mkittler over 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

Actions #8

Updated by okurz over 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 :)

Actions

Also available in: Atom PDF