action #120964
closed[security][qem] test fails in SLE 12-SP5 sssd_openldap_functional, timeout
Added by tjyrinki_suse over 1 year ago. Updated over 1 year ago.
100%
Description
Observation¶
openQA test in scenario sle-12-SP5-Server-DVD-Updates-x86_64-sssd_openldap_functional@64bit fails in
sssd_openldap_functional
Times out at or around/after "Refreshing service 'container-suseconnect-zypp'." Happens both on x86_64 and aarch64.
Further details¶
Always latest result in this scenario: latest
Suggestion¶
Line 48 in sssd_openldap_functional.pm should probably have longer timeout than 600.
Updated by tjyrinki_suse over 1 year ago
- Status changed from New to In Progress
- Assignee set to tjyrinki_suse
Updated by tjyrinki_suse over 1 year ago
Updated by tjyrinki_suse over 1 year ago
The PR seems to get it further, but eventually it fails a bit like https://progress.opensuse.org/issues/113692 did, so might be an maintenance update issue.
Updated by tjyrinki_suse over 1 year ago
Pass: https://openqa.suse.de/tests/10024804/logfile?filename=serial_terminal.txt
Earlier pass: https://openqa.suse.de/tests/10017474/logfile?filename=serial_terminal.txt
Fail: https://openqa.suse.de/tests/10038608/logfile?filename=serial_terminal.txt
Pass:
Step 11/18 : RUN zypper install -y $pkgs
---> Running in a0865f66b118
Refreshing service 'container-suseconnect-zypp'.
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following 7 NEW packages are going to be installed:
gawk libdb-4_8 libltdl7 openldap2 openslp sudo update-alternatives
7 new packages to install.
Overall download size: 4.2 MiB. Already cached: 0 B. After the operation, additional 14.3 MiB will be used.
Continue? y/n/v/...? shows all options: y
Retrieving package libdb-4_8-4.8.30-28.6.1.x86_64 (1/7), 670.8 KiB ( 3.1 MiB unpacked)
Retrieving: libdb-4_8-4.8.30-28.6.1.x86_64.rpm [done]
Retrieving package openslp-2.0.0-6.15.1.x86_64 (2/7), 64.7 KiB (139.5 KiB unpacked)
Retrieving: openslp-2.0.0-6.15.1.x86_64.rpm [done]
Retrieving package libltdl7-2.4.6-3.4.1.x86_64 (3/7), 32.6 KiB ( 38.6 KiB unpacked)
Retrieving: libltdl7-2.4.6-3.4.1.x86_64.rpm [done]
Retrieving package sudo-1.9.5p2-150300.3.13.1.x86_64 (4/7), 1.1 MiB ( 4.4 MiB unpacked)
Retrieving: sudo-1.9.5p2-150300.3.13.1.x86_64.rpm [done]
Retrieving package update-alternatives-1.19.0.4-150000.4.4.1.x86_64 (5/7), 43.5 KiB ( 69.7 KiB unpacked)
Retrieving: update-alternatives-1.19.0.4-150000.4.4.1.x86_64.rpm [done]
Retrieving package gawk-4.2.1-1.41.x86_64 (6/7), 1.2 MiB ( 3.1 MiB unpacked)
Retrieving: gawk-4.2.1-1.41.x86_64.rpm [done]
Retrieving package openldap2-2.4.46-150200.14.11.2.x86_64 (7/7), 1.1 MiB ( 3.4 MiB unpacked)
Retrieving: openldap2-2.4.46-150200.14.11.2.x86_64.rpm [done]
...
Fail:
Step 11/18 : RUN zypper install -y $pkgs
---> Running in 8a57139f10fa
Refreshing service 'container-suseconnect-zypp'.
Problem retrieving the repository index file for service 'container-suseconnect-zypp':
[container-suseconnect-zypp|file:/usr/lib/zypp/plugins/services/container-suseconnect-zypp]
Warning: Skipping service 'container-suseconnect-zypp' because of the above error.
Loading repository data...
Reading installed packages...
Resolving package dependencies...
2 Problems:
Problem: nothing provides 'libcrypto.so.1.0.0()(64bit)' needed by the to be installed openldap2-2.4.41-22.16.1.x86_64
Problem: nothing provides 'libcrypto.so.1.0.0()(64bit)' needed by the to be installed libldap-2_4-2-2.4.41-22.16.1.x86_64
Problem: nothing provides 'libcrypto.so.1.0.0()(64bit)' needed by the to be installed openldap2-2.4.41-22.16.1.x86_64
Solution 1: do not install openldap2-2.4.41-22.16.1.x86_64
Solution 2: break openldap2-2.4.41-22.16.1.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or skip, retry or cancel 1/2/s/r/c/d/?: c
openldap is already installed in the failing case?
Updated by tjyrinki_suse over 1 year ago
- Status changed from In Progress to New
- Assignee deleted (
tjyrinki_suse) - Estimated time changed from 4.00 h to 0.00 h
Unassigning since I'm not here on Monday.
Updated by tjyrinki_suse over 1 year ago
- Estimated time changed from 0.00 h to 8.00 h
Updated by tjyrinki_suse over 1 year ago
- Priority changed from Normal to High
High priority because in maintenance updates.
Updated by pstivanin over 1 year ago
- Status changed from New to In Progress
- Assignee set to acarvajal
- % Done changed from 0 to 20
Updated by pstivanin over 1 year ago
- % Done changed from 20 to 50
As we can see from the logs, we can confirm that this is a timeout issue:
First executed:
[2022-11-25T11:22:21.606713+01:00] [debug] <<< testapi::assert_script_run(cmd="docker build
...
after 10 minutes it's still running, therefore it's terminated:
[2022-11-25T11:33:51.940202+01:00] [info] ::: basetest::runtest: # Test died:
...
timed out at /usr/lib/os-autoinst/testapi.pm line 881.
Updated by szarate over 1 year ago
Looks like you need to ask somebody on ibs, 10 minutes to build that container seems to be a bit too much...? but if it isn't network, maybe there's a peformance hit somewhere else?
Updated by pstivanin over 1 year ago
- Assignee changed from acarvajal to tjyrinki_suse
- % Done changed from 50 to 100
I saw that Timo opened a PR to increase the timeout, I've merged it.
Since this has happened only 3 times in the past weeks, it must be something performance related. Not sure if it is worth to spend more time into this right now. What do you think @Timo?
Updated by tjyrinki_suse over 1 year ago
- Status changed from In Progress to Resolved
@Paolo I think you are correct, it's still annoying when it happens and blocks the maintenance updates. Thanks for merging!