action #54041


test terminates in openqa in scenario with raid partitioning

Added by ybonatakis almost 5 years ago. Updated almost 5 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


One of the test that shows the problem is the lvm+raid1.

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 ( 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.


Actions #1

Updated by okurz almost 5 years ago

  • Category set to Support
  • Status changed from New to Feedback
  • Assignee set to okurz

From :

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/ 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

Actions #2

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.

Actions #3

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.


Also available in: Atom PDF