After Upgrade 2020/09: Repository errors; increased shared memory usage
Hi, some days ago I attempted to upgrade our Uyuni system again and this time I was more lucky than in the past. The upgrade path was 2020/04 on opensuse-15.1 to 2020/09 (on opensuse-15.2). The procedure is described at the end of the mail. Since the upgrade there are two issues: 1.) During the daily sync of the repositories (SLES15-SP1 and SLES15-SP2) the system reports messages at the Web-GUI for every channel like this one: Creating Bootstrap Repository failed Error generating bootstrap repo for: SLE-15-SP2-x86_64 "Details" show: ERROR: package 'python3-hwdata' not found ERROR: package 'python3-rhnlib' not found ERROR: package 'spacewalk-check' not found ERROR: package 'spacewalk-client-setup' not found ERROR: package 'spacewalk-client-tools' not found ERROR: package 'python3-spacewalk-check' not found ERROR: package 'python3-spacewalk-client-setup' not found ERROR: package 'python3-spacewalk-client-tools' not found ERROR: none of 'mgr-daemon', 'spacewalksd' found ERROR: package 'suseRegisterInfo' not found ERROR: package 'python3-suseRegisterInfo' not found ERROR: package 'zypp-plugin-spacewalk' not found ERROR: package 'python3-zypp-plugin-spacewalk' not found The synchronization of the channels seems to be successful as there are reports of new patches. The updates of the clients work fine, too. 2.) The usage of shared memory has increased significantly since the upgrade. 24 h after restart of the PostgreSQL-DB its level is nearly 2 GB which is 25%. ipcs says that this is the only process using it. Is this normal? Does the system need more memory? FYI - the upgrade was done according to https://www.uyuni-project.org/doc/2020.09/uyuni_upgrade_guide.pdf with these tasks in short (leaving out backup and snapshot of the system powered off): (Enabling all repositories) spacewalk-service stop zypper ref zypper up susemanager /usr/lib/susemanager/bin/server-migrator.sh /usr/lib/susemanager/bin/pg-migrate-10-to-12.sh fast reboot Thanks for any hints! Regards, Tobias.
Hi Am Donnerstag, 26. November 2020, 14:19:09 CET schrieb Tobias Crefeld:
Hi,
some days ago I attempted to upgrade our Uyuni system again and this time I was more lucky than in the past. The upgrade path was 2020/04 on opensuse-15.1 to 2020/09 (on opensuse-15.2). The procedure is described at the end of the mail.
Since the upgrade there are two issues:
1.) During the daily sync of the repositories (SLES15-SP1 and SLES15-SP2) the system reports messages at the Web-GUI for every channel like this one:
Creating Bootstrap Repository failed Error generating bootstrap repo for: SLE-15-SP2-x86_64
"Details" show: ERROR: package 'python3-hwdata' not found ERROR: package 'python3-rhnlib' not found ERROR: package 'spacewalk-check' not found ERROR: package 'spacewalk-client-setup' not found ERROR: package 'spacewalk-client-tools' not found ERROR: package 'python3-spacewalk-check' not found ERROR: package 'python3-spacewalk-client-setup' not found ERROR: package 'python3-spacewalk-client-tools' not found ERROR: none of 'mgr-daemon', 'spacewalksd' found ERROR: package 'suseRegisterInfo' not found ERROR: package 'python3-suseRegisterInfo' not found ERROR: package 'zypp-plugin-spacewalk' not found ERROR: package 'python3-zypp-plugin-spacewalk' not found
The synchronization of the channels seems to be successful as there are reports of new patches. The updates of the clients work fine, too.
You miss the uyuni-client-tools channel. Check https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/clients-... for "spacewalk-common-channels" command When you use salt, you do not need them, but also some other packages which might be useful on a client are not available for you. And it will make the errors go away. Other option would be to disable the auto generation of the bootstrap repo. See https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/bootstra...
2.) The usage of shared memory has increased significantly since the upgrade. 24 h after restart of the PostgreSQL-DB its level is nearly 2 GB which is 25%. ipcs says that this is the only process using it. Is this normal? Does the system need more memory?
Hmm, you made a big jump and I think we made some heavy changes in repo-sync. We made the import of packages now in parallel and this bring much more tasks to your server and speed up the import process a lot. This could be the reason for what you see. And more memory is always good for a database and it takes what it can get :-)
FYI - the upgrade was done according to https://www.uyuni-project.org/doc/2020.09/uyuni_upgrade_guide.pdf with these tasks in short (leaving out backup and snapshot of the system powered off):
(Enabling all repositories) spacewalk-service stop zypper ref zypper up susemanager /usr/lib/susemanager/bin/server-migrator.sh /usr/lib/susemanager/bin/pg-migrate-10-to-12.sh fast reboot
Thanks for any hints!
Regards, Tobias. _______________________________________________ Uyuni Users mailing list -- users@lists.uyuni-project.org To unsubscribe, email users-leave@lists.uyuni-project.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/users@lists.uyuni-project.org
-- Regards Michael Calmer -------------------------------------------------------------------------- Michael Calmer SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg T: +49 (0) 911 74053 0 F: +49 (0) 911 74053575 - e-mail: Michael.Calmer@suse.com -------------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer (HRB 36809, AG Nürnberg)
On Thu, 26 Nov 2020 15:38:21 +0100 Michael Calmer <mc@suse.de> wrote:
You miss the uyuni-client-tools channel. Check https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/clients-... for "spacewalk-common-channels" command
When you use salt, you do not need them, but also some other packages which might be useful on a client are not available for you. And it will make the errors go away.
So this channel is something that wasn't needed in the past (= 2020/04)? What do you mean with "using salt"? Till now my understanding was that distribution of software and configuration by Uyuni is always done with salt!?
Other option would be to disable the auto generation of the bootstrap repo. See https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/bootstra...
You write "generation", the document says "regeneration" and the configuration item contains the word "generate". Does disabling "server.susemanager.auto_generate_bootstrap_repo" only mean, that the bootstrap repository stays as it is? Or would it mean as well that in future selecting a new "product" like SLES15-SPx no bootstrap repository will be created and bootstrapping new clients with this product won't work?
Hmm, you made a big jump and I think we made some heavy changes in repo-sync. We made the import of packages now in parallel and this bring much more tasks to your server and speed up the import process a lot. This could be the reason for what you see.
Sounds plausible as the increase happens during the night when repositories get synced. Speeding up initial synchronizations is interesting but IMHO for daily updates this is no advantage. It would be fine if it gave back the memory after some time in order to get used for caching during the day. But ok. - if this memory consumption is comprehensible, increasing the limit in our monitoring will be enough for now. Regards, Tobias.
participants (2)
-
Michael Calmer -
Tobias Crefeld