Bug 1749017
Summary: | Spending a long time to validate the hostname when proceeding with the restore | ||
---|---|---|---|
Product: | Red Hat Satellite | Reporter: | Waldirio M Pinheiro <wpinheir> |
Component: | Satellite Maintain | Assignee: | Waldirio M Pinheiro <wpinheir> |
Status: | CLOSED ERRATA | QA Contact: | Lucie Vrtelova <lvrtelov> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.5.0 | CC: | apatel, aupadhye, gtalreja, inecas, jpathan, kgaikwad, lvrtelov, mbacovsk, pcreech, zhunting |
Target Milestone: | 6.9.0 | Keywords: | Triaged, UserExperience |
Target Release: | Unused | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Fixed In Version: | rubygem-foreman_maintain-0.7.2-1 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2021-04-21 14:48:22 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Waldirio M Pinheiro
2019-09-04 17:15:04 UTC
Hi all To complement, the foreman-maintain logs --- D, [2019-09-02 21:01:22-0400 #23867] DEBUG -- : Running command tar zxf /backup/satellite-backup-2019-08-05-09-41-02/config_files.tar.gz etc/httpd/conf/httpd.conf --to-stdout | grep ServerName | awk {'print $2'} | tr -d '"' with stdin nil --- From the BZ description it looks like etc/httpd/conf/httpd.conf file extraction from the backup tarball is taking a lot of time. Can we have an idea about: 1. Where is the backup archive stored? (type of storage) 2. How big is the config_files.tar.gz file? 3. A rough estimate on how long does this task take? Hello, Thanks for your response. > 1. Where is the backup archive stored? (type of storage) A: Could be regular filesystem or NFS. On my test, local storage was used. > 2. How big is the config_files.tar.gz file? A: This will vary according to the customer environment but let me show this example --- # ll total 4396656 -rw-r--r--. 1 root root 28920002265 Sep 9 16:21 config_files.tar.gz ... # du -hs config_files.tar.gz 33G config_files.tar.gz --- Then let's get the information on this file. --- # time tar zxf config_files.tar.gz etc/httpd/conf/httpd.conf --to-stdout | grep ^ServerName ServerName "wallsat67.usersys.redhat.com" << Long time here, probably all the 7 minutes >>> real 7m0.350s user 5m30.999s sys 1m14.056s --- Note. We got the result on the screen real quick, however, once the command is checking the whole file, this process will spend some additional time. > 3. A rough estimate on how long does this task take? A: Above. 33G is a huge one, this is from my lab machine that I use every day, sometimes we got scenarios like this, sometimes 10G, 15G, 5G ... will really be according to the customer environment. Below we can see the solution. Using "--occurrence=1" once the tar find the first one, the process will get out and move on. --- # time tar zxf config_files.tar.gz etc/httpd/conf/httpd.conf --to-stdout --occurrence=1 | grep ^ServerName ServerName "wallsat67.usersys.redhat.com" real 0m0.257s user 0m0.029s sys 0m0.046s --- Thank you! Waldirio Upstream bug assigned to wpinheir Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/30809 has been resolved. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Satellite 6.9 Satellite Maintenance Release), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:1312 |