Resolved mariadb.service deactivates itself after Plesk update

[Gary W.]

I haven't touched the server in months. After the Plesk Onyx update on February 15, 2024, some of the WordPress sites started to crash.
I open the Plesk recovery kit and notice that the mariadb.service service has been disabled from the system (I didn't touch it).

Relaunching the service solved the problem, what could have caused the problem?

How to prevent it from happening again?

 

[Peter Debik]

Please examine /var/log/messages (or your syslog that might be named a bit different according to your operating system) for "mariadb" messages. Normally Maria can crash when it encounters a corrupt table. Such information will be logged to the syslog.

 

[Gary W.]

Today it happened again after Plesk Obsidian 18.0.59 Update 1. It seems that after every plesk update maria.db is deactivated and manual intervention is required to restore it. The server has been standing for 5 years without any problem.

Now in the space of a month the collapse.

 

[Peter Debik]

Have you checked /var/log/messages (/var/log/syslog) for mariadb related entries at the time of the error?

 

[Gary W.]

Seems like dnf-makecache.service fails:

 Execution status has failed with exit code 3, stdout: × dnf-makecache.service - dnf makecache
     Loaded: loaded (/usr/lib/systemd/system/dnf-makecache.service; static)
     Active: failed (Result: signal) since Tue 2024-03-05 00:10:47 UTC; 1min 10s ago
TriggeredBy: ● dnf-makecache.timer
    Process: 30557 ExecStart=/usr/bin/dnf makecache --timer (code=killed, signal=KILL)
   Main PID: 30557 (code=killed, signal=KILL)
        CPU: 49.880s

Mar 05 00:04:49 angry-lamport.49-13-161-139.plesk.page systemd[1]: Starting dnf makecache...
Mar 05 00:04:50 angry-lamport.49-13-161-139.plesk.page dnf[30557]: AlmaLinux 9 - AppStream                         9.4 kB/s | 4.1 kB     00:00
Mar 05 00:04:50 angry-lamport.49-13-161-139.plesk.page dnf[30557]: AlmaLinux 9 - BaseOS                             11 kB/s | 3.8 kB     00:00
Mar 05 00:04:51 angry-lamport.49-13-161-139.plesk.page dnf[30557]: AlmaLinux 9 - CRB                                12 kB/s | 4.1 kB     00:00
Mar 05 00:04:51 angry-lamport.49-13-161-139.plesk.page dnf[30557]: AlmaLinux 9 - Extras                             11 kB/s | 3.8 kB     00:00
Mar 05 00:04:51 angry-lamport.49-13-161-139.plesk.page dnf[30557]: Extra Packages for Enterprise Linux 9 - x86_64  572 kB/s |  35 kB     00:00
Mar 05 00:10:47 angry-lamport.49-13-161-139.plesk.page systemd[1]: dnf-makecache.service: Main process exited, code=killed, status=9/KILL
Mar 05 00:10:47 angry-lamport.49-13-161-139.plesk.page systemd[1]: dnf-makecache.service: Failed with result 'signal'.
Mar 05 00:10:47 angry-lamport.49-13-161-139.plesk.page systemd[1]: Failed to start dnf makecache.
Mar 05 00:10:47 angry-lamport.49-13-161-139.plesk.page systemd[1]: dnf-makecache.service: Consumed 49.880s CPU time.
, stderr:

This process keeps updating in background and keep using 100% of the resources on my server:



How can I fix this?

 

[Peter Debik]

Please continue your investigation with /var/log/dnf.log. If DNF fails, the reason should be logged to it.

 

[Xyn Host]

I am facing the same issue just randomly.

 

[Gary W.]

I am facing the same issue just randomly.

In the end, I discovered that I was running low on RAM, which caused the service to reach saturation and shut down. If you don't want to increase the RAM, ask Claude or OpenAI to create a script to restart MariaDB. Once created, you need to upload it to the server via FTP (ask the AI how to do that). That's how I solved the problem, and I never had the same issue again.