Project

General

Profile

action #81116

openqa-webui is failed to start because /var/lib/openqa/db/db.lock owned by vnc user

Added by asmorodskyi 7 months ago. Updated 7 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Support
Target version:
Start date:
2020-12-16
Due date:
2020-12-23
% Done:

0%

Estimated time:
Difficulty:

Description

Following instructions defined https://github.com/os-autoinst/openQA/blob/master/docs/Installing.asciidoc at step https://github.com/os-autoinst/openQA/blob/master/docs/Installing.asciidoc#run-the-web-ui getting following :

Dec 16 14:40:40 dante systemd[1]: Started The openQA web UI.
Dec 16 14:40:41 dante openqa-webui-daemon[2728]: Can't open database lock file /var/lib/openqa/db/db.lock! at /usr/share/openqa/script/../lib/OpenQA/Schema.pm line 88.
Dec 16 14:40:41 dante systemd[1]: openqa-webui.service: Main process exited, code=exited, status=13/n/a
Dec 16 14:40:41 dante systemd[1]: openqa-webui.service: Unit entered failed state.
Dec 16 14:40:41 dante systemd[1]: openqa-webui.service: Failed with result 'exit-code'.

checking /var/lib/openqa/db/db.lock gives that file is owned by vnc user and available to others only with read access ( 644 ).
package version info :

zypper info openQA
Loading repository data...
Reading installed packages...


Information for package openQA:
-------------------------------
Repository     : devel_openQA
Name           : openQA
Version        : 4.6.1608127273.ff2a1bfcf-lp152.3540.1
Arch           : noarch
Vendor         : obs://build.opensuse.org/devel:openQA
Installed Size : 12.0 MiB
Installed      : Yes
Status         : out-of-date (version 4.6.1608019100.3a581bf95-lp152.3539.1 installed)

History

#1 Updated by okurz 7 months ago

  • Category set to Concrete Bugs
  • Status changed from New to Feedback
  • Assignee set to okurz
  • Target version set to Ready

In chat you say "fresh install" but likely you are already aware that this is of course part of multiple automatic tests, including the "openQA-in-openQA" tests. So I wonder if that was really a "fresh" system after all? Can you reproduce this? Maybe in a container environment?

#2 Updated by asmorodskyi 7 months ago

okurz wrote:

In chat you say "fresh install" but likely you are already aware that this is of course part of multiple automatic tests, including the "openQA-in-openQA" tests. So I wonder if that was really a "fresh" system after all? Can you reproduce this? Maybe in a container environment?

system was installed yesterday from scratch specifically for openQA install . so it is really fresh install . only thing which which probably worth to mention that order of steps was a mixed because initially system was suppose to be only for workers but later it got changed to "openQA standalone setup" . so at first I did zypper in openQA-worker and only than zypper in openQA

#3 Updated by okurz 7 months ago

  • Due date set to 2020-12-23
  • Category changed from Concrete Bugs to Support

asmorodskyi wrote:

[…] only thing which which probably worth to mention that order of steps was a mixed because initially system was suppose to be only for workers but later it got changed to "openQA standalone setup" . so at first I did zypper in openQA-worker and only than zypper in openQA

Right. I saw that from dante.arch.suse.de:/var/log/zypp/history so I used the same install steps in a test container environment. However I could not reproduce the permission problem on /var/lib/openqa/db/db.lock . Installing zypper -n in xorg-x11-Xvnc-module xorg-x11-Xvnc created the "vnc" user but of course this does not change the permission of /var/lib/openqa/db/db.lock retroactively.

I tried again in a container environment where I installed first zypper -n in xorg-x11-Xvnc-module xorg-x11-Xvnc which created the VNC user and only then install zypper -n in openQA but this did not trigger this problem. Unfortunately you have not configured dante to have persistent system journal (to do this just create mkdir /var/log/journal/) so I could not check the system journal from yesterday and hence have found nothing else that could explain what could have happened.

Unless you can reproduce the problem I don't see it possible to come up with any improvement.

#4 Updated by asmorodskyi 7 months ago

I also tried to reproduce it on Leap VM installed from scratch and also failed so I think this one can be closed

#5 Updated by okurz 7 months ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF