action #81116
closedopenqa-webui is failed to start because /var/lib/openqa/db/db.lock owned by vnc user
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)
Updated by okurz over 3 years ago
- Category set to Regressions/Crashes
- 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?
Updated by asmorodskyi over 3 years 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
Updated by okurz over 3 years ago
- Due date set to 2020-12-23
- Category changed from Regressions/Crashes 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-workerand only thanzypper 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.
Updated by asmorodskyi over 3 years ago
I also tried to reproduce it on Leap VM installed from scratch and also failed so I think this one can be closed