action #54041
closedtest terminates in openqa in scenario with raid partitioning
0%
Description
One of the test that shows the problem is the lvm+raid1. http://aquarius.suse.cz/tests/1666
The test seems to go far as in the user_settings module and then it crushes. The first impression was that it might be because of the disk space size. But the disk has enough space for 20Gx4 disks.
The openQA has been updated and run openQA-4.6.1562654601.3adf2e38-1537.1.noarch. os-autoinst is os-autoinst-4.5.1562413838.c3d5e8ac-131.1.x86_64.
in one of the attempt i disabled the firewall because it couldnt upload anything but nothing changed. this causes the openQA to not contains logs of the sut.
the logs collected by the last run (http://aquarius.suse.cz/tests/1666) is here[0] and journalctl logs here [1] which reports an API-failure.
Other jobs looks to work as expected. first time i run the test i used MAKETESTSNAPSHOTS but even without it didnt make any difference.
[0] http://susepaste.org/view//65176897
[1] http://susepaste.org/view//26124785
Updated by okurz almost 5 years ago
- Category set to Support
- Status changed from New to Feedback
- Assignee set to okurz
From http://susepaste.org/view//26124785 :
Jul 09 17:26:02 aquarius worker[2938]: [error] 400 response: DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::Pg::st execute failed: ERROR: duplicate key value violates unique constraint "needles_dir_id_filename"
Jul 09 17:26:02 aquarius worker[2938]: DETAIL: Key (dir_id, filename)=(3, partitioning_raid-hard_disks-unfolded-icon_scheme-20181217.json) already exists. [for Statement "UPDATE needles SET last_matched_module_id = ?, last_matched_time = ?, last_seen_module_id = ?, last_seen_time = ?, t_updated = ? WHERE ( id = ? )" with ParamValues: 1='25325', 2='2019-07-09 15:25:56', 3='25325', 4='2019-07-09 15:25:56', 5='2019-07-09 15:26:02', 6='5697'] at /usr/share/openqa/script/../lib/OpenQA/Schema/Result/Needles.pm line 102
The only hint I can give right now is to debug why you have that DB exception about needledir. Maybe you did something special regarding your directory structure. You could look into the database manually with psql or recreate the DB
Updated by ybonatakis almost 5 years ago
recreating the database seemed that the disturbing failure has disappeared. still not sure what caused it or how to reproduce it to investigate.
@okurz you may want to close this ticket.
Updated by okurz almost 5 years ago
- Status changed from Feedback to Resolved
ok, fine. Thanks for the update. With more debugging on the old database content I guess there is not much sense in trying to fix whatever was the original problem.