Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

package search results empty - package index for rhn-search does not seem to be created after restart of container #9171

Open
fd-SR opened this issue Aug 15, 2024 · 4 comments
Labels
bug Something isn't working question Further information is requested

Comments

@fd-SR
Copy link

fd-SR commented Aug 15, 2024

Question

Not sure if this is a question or a bug.
We are running a containerized uyuni-server 2024.07 which was recently migrated from a legacy setup (also 2024.07).
The original server has been running for a few years with a number of software channels, so it contains quite a few packages.
After restarting the container and then trying a package search in the Web GUi (eg 'kernel'), it always returns no packages.
No error - just no matching packages found.
When looking into this I realized that /var/lib/rhn/search/indexes/ is not part of a persistent volume so these indexes need to be recreated every time the container starts. Which looks like it does fine for hwdevice, server, etc., but not for the package folder. While the WebGUI just states no packages found, the /var/log/rhn/search/rhn-search.log states
ERROR - no segments* file found in org.apache.lucene.store.FSDirectory@/var/lib/rhn/search/indexes/package: files:
for each search request done in the GUI.
I also checked for errors suggested in other tickets related to rhn-search, like OutOufMemory ones but could not find any.
I then tried rhn-search cleanindex and the indexes get recreated which fixes the issue.

So my question is when or by which bunch the package index is supposed to be refreshed/recreated after a restart of the container?
To give more context we are running a daily backup routine and are stopping and starting the container for that.
So maybe this is just a matter of us needing to reschedule things a bit.

Version of Uyuni Server and Proxy (if used)

Information for package Uyuni-Server-release:

Repository : @System
Name : Uyuni-Server-release
Version : 2024.07-230900.219.1.uyuni3
Arch : x86_64
Vendor : obs://build.opensuse.org/systemsmanagement:Uyuni
Installed Size : 1.4 KiB
Installed : Yes (automatically)
Status : up-to-date
Source package : Uyuni-Server-release-2024.07-230900.219.1.uyuni3.src
Upstream URL : https://www.uyuni-project.org/
Summary : Uyuni Server
Description :
Uyuni lets you efficiently manage physical, virtual,
and cloud-based Linux systems. It provides automated and cost-effective
configuration and software management, asset management, and system
provisioning.

@fd-SR fd-SR added the question Further information is requested label Aug 15, 2024
@mbussolotto
Copy link
Member

@fd-SR thanks for reporting it.
@cbosdo seems we missed to persist /var/lib/rhn/search/indexes/

@cbosdo
Copy link
Contributor

cbosdo commented Sep 26, 2024

Either we persist them or we recreate them at container startup

@cbosdo cbosdo added the bug Something isn't working label Sep 26, 2024
@mcalmer
Copy link
Contributor

mcalmer commented Sep 26, 2024

Re-creating the index may take long depending on how many data you have.
It indexes all packages and all systems. This can take multiple hours

@rjmateus
Copy link
Member

We must persist the search indexes, as Michael says, it can take several hour in worth case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working question Further information is requested
Projects
None yet
Development

No branches or pull requests

5 participants