Hi,
This is my first message on the forum - so let me start by thanking all the developers and the entire RockyLinux community for a great job!
Many times I based my management on advice from the forum or from the documentation itself. Thanks for such a great community
Ok - I had to write because I’m struggling with a problem related to macecache service on RapsberryPi 3.
After some refresh, the service terminates with an error. I read somewhere that this may be due to RAM shortages - the RPi is limited, and mine is still heavily loaded with other services.
So my question - because as I understand it, the macecache is supposed to crank out before waiting for package refreshes. In that case, because that’s how I read it - if I don’t care so much about the speed of the update, will disabling this service and every time waiting for the repo to refresh before possibly installing it just be an inconvenience for me? Or can it cause other problems?
What does it look like in practice? In general, I have disabled this service, I see no other problems - so I assume that my reasoning is correct on this topic?
I think you mean makecache , with a “k” , right? If you look at the .service file ( /usr/lib/systemd/system/dnf-makecache.service ), you see that it’s running this command: /usr/bin/dnf makecache --timer . It simply launches the dnf package manager and pulls fresh information about each Rocky repository (BaseOS, Appstream, etc.).
The idea is to keep the metadata “fresh” so dnf doesn’t have to do this when you go to install, update or other operations. It’s safe to disable if it’s causing problems - systemctl disable dnf-makecache.timer .
It’s a little concerning if that’s causing you to run out of memory… you might try running dnf makecache yourself, and monitoring memory/swap usage with free -m while it’s running. See if memory is the issue, or something else is going on.
Hi,
Of course I meant makecache - typo
Thanks for the clarification - which was ultimately in line with my self-check. I was just curious if I interpreted correctly the very operation of this service for DNF.
I will test it after the weekend.
Due to the fact that I have a “production” server on the Raspberry, and the test image from the original distribution I have made as in a virtual machine, and there I did not experience such errors - I assume that this may also be related to the release itself on the RaspberryPi.
I wanted to eliminate the problem quickly, and I will do further testing after the weekend.
