I have a Linode VPS running CentOS 7 and somewhat old versions of web-related services (because code I've written isn't ready for newer versions - I'm planning to build a fresh VPS with new everything and updated code, but that will take time).

Recently the VPS migrated to new hardware. After the reboot, MariaDB 10.2 would not restart. After two days of tearing my hair out, I got it working by removing and reinstalling mariadb-server, plus careful file management to get it to recognize my InnoDB data files.

MariaDB 10.2 is end of life and no longer supported as of May 2022, therefore is no longer in http://yum.mariadb.org, so I had to install 10.4 (I only changed one digit in MariaDB.repo, from baseurl=http://yum.mariadb.org/10.2/centos7-amd64 to baseurl=http://yum.mariadb.org/10.4/centos7-amd64).

Everything is running fine as far as I can tell. However, whenever I try to get Monit to start monitoring that service again, it refuses, and I get two notification emails saying "Checksum failed Service mariadb_bin" and "Checksum failed Service mariadb_init".

I used the most authoritative mirror, right? So why is there a checksum problem?

Here is the Monit file for MariaDB:

## Mariadb monitoring.

## Test the mariadb service.
check process mariadb with pidfile /run/mariadb/mariadb.pid
  group database
  start program = "/usr/bin/systemctl start mariadb"
  stop  program = "/usr/bin/systemctl stop mariadb"
  restart program  = "/usr/bin/systemctl restart mariadb"
  if failed port 3306 protocol mysql then restart
  if 3 restarts within 5 cycles then timeout
  # This process check depends on checking the binary if the mariadb
  # daemon and the init script.
  depends on mariadb_bin
  depends on mariadb_init
  alert [my email address] only on {timeout}

## Test the process binary.
check file mariadb_bin with path /usr/bin/mysqld_safe
  group database
  if failed checksum then unmonitor
  if failed permission 755 then unmonitor
  if failed uid root then unmonitor
  if failed gid root then unmonitor

## Test the init scripts.
check file mariadb_init with path /usr/lib/systemd/system/mariadb.service
  group database
  if failed checksum then unmonitor
  if failed permission 644 then unmonitor
  if failed uid root then unmonitor
  if failed gid root then unmonitor

So apparently Monit is saying that the checksum of mariadb_bin does not match that of /usr/bin/mysqld_safe and the checksum of mariadb_init does not match that of /usr/lib/systemd/system/mariadb.service, although I don't know what a "group database" is.

  • What is the checksum of the binary and the source reference file /usr/bin/mysqld_safe?
    – Greg Askew
    Nov 30, 2023 at 11:30
  • The email about mariadb_bin says, "Description: checksum failed, expected c62b4968d8ce7ba7e585e9239621ef70 got 81bddac97dcdda98f9a54b27748d87af", so I guess /usr/bin/mysqld_safe is c62b4968d8ce7ba7e585e9239621ef70. Similarly, the email for mariadb_init says, "expected 755e9effc91b51db187a1af8a045b0ae got 72e257e87d58f09e0d74abae0a2e1007". Nov 30, 2023 at 21:10

2 Answers 2


Nice to see you use the Monit sample to handle a MySQL/Maria DB server, see https://mmonit.com/wiki/Monit/ConfigurationExamples#mysqld

The checksum test is nice, but only of limited (not very) use in the real world (I think).

To get the right checksum of the file you can use "monit -H filename" and you can add the expected vaule to the test, see https://mmonit.com/monit/documentation/monit.html#FILE-CHECKSUM-TEST

Monit store the checksum in the Monit state file. You update the MariaDB, therefore the files are changed, and the checksum also. You can delete the state file, to remove the old values or add the expected values to the test (my preferred way), see https://mmonit.com/monit/documentation/monit.html#FILES

The "group database" is the Monit way to group application, see https://mmonit.com/monit/documentation/monit.html#SERVICE-GROUPS

Some suggestions only, Lutz


As it turns out, after the reinstall of MariaDB I had not done the apparently obvious step of reloading Monit (newbie - sorry!). So that's the key point making this an "answer" that might help other people.

In my case, though, after reloading Monit and trying to get it to resume monitoring of MariaDB, it had a new complaint - it said the service didn't even exist, even though my databases are running fine. Digging around more, I discovered that there is no longer a file called /run/mariadb/mariadb.pid (in fact, even the /run/mariadb directory doesn't exist now). Doing find / -name *.pid and looking through the list for likely candidates, I spotted /var/lib/mysql/puphpet2.pid ("puphpet2" is the name of my Linode VPS). It has a timestamp of just a few minutes ago, which is surprising - I haven't knowingly restarted MariaDB since I installed it a few weeks ago. But its contents does match pidof mysqld. So I edited /etc/monit.d/mariadb with that as the pidfile, and Monit now says it is happily monitoring MariaDB (with no checksum complaints either). I hope that's the right thing to do - if not, let me know and I'll retract this as my answer, but otherwise I'll assume it's correct (and potentially useful to someone else having trouble).

  • Sounds good, I think. Sometimes the pid file or program file name is changed and the Monit configuration must changed therefore. A reload should reload/update the checksum, in general, I define the expected value in the configuration.
    – lutzmad
    Dec 19, 2023 at 12:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .