The solution to the warning “mismatch_cnt is not 0 on /dev/md*”

Replaced once the junk drive in the software RAID1, added it to the raid, it successfully synchronized, installed GRUB.
After a while I received an email message:

Subject: Cron <root@server> /usr/sbin/raid-check
WARNING: mismatch_cnt is not 0 on /dev/md2

In my case, raid-check found that the mismatch_cnt counter is not equal to 0 for /dev/md2, which means that there may be broken sectors on the disk, or it simply needs to be resynchronized. Since I installed GRUB after adding the disk to the raid, this is probably the cause.

Example of viewing the counters of all arrays:

cat /sys/block/md*/md/mismatch_cnt

Or each in turn:

cat /sys/block/md0/md/mismatch_cnt
cat /sys/block/md1/md/mismatch_cnt
cat /sys/block/md2/md/mismatch_cnt

View the status of raids:

cat /sys/block/md*/md/sync_action

If mismatch_cnt is not 0 for any array, then you can try to resynchronize it:

echo 'repair' >/sys/block/md2/md/sync_action

And check:

echo 'check' >/sys/block/md2/md/sync_action

If you want to cancel the action:

echo 'idle' >/sys/block/md2/md/sync_action

Let’s see the synchronization status and other data of the array:

cat /proc/mdstat

If errors appear due to a bad disk, I recommend that you look at SMART and check it as I wrote in these articles:
Diagnostics HDD using smartmontools
Linux disk test for errors and broken sectors

See also:
How to fix the problem with mdadm disks

Troubleshooting PHP Warning “Permission denied /var/cpanel/php/sessions/ea-php56/”

Once I updated EasyApache 3 to EasyApache 4 in cPanel and noticed in the PHP logs the following:

[29-Mar-2018 15:54:45 UTC] PHP Warning:  Unknown: open(/var/cpanel/php/sessions/ea-php56/sess_3d96o7nnlnnr473p8619vqkdm1, O_RDWR) failed: Permission denied (13) in Unknown on line 0
[29-Mar-2018 15:54:45 UTC] PHP Warning:  Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/cpanel/php/sessions/ea-php56) in Unknown on line 0

The warning occurs because PHP can not write session files to a directory to which it does not have access rights.
I looked at the rights of this directory, the group and owner was root, and it was also allowed to write and execute for everyone, except reading.

To resolve this warning, you can open full access for everyone:

chmod 777 /var/cpanel/php/sessions/ea-php56

Or open a PHP configuration, for example in the nano editor:

nano /opt/cpanel/ea-php56/root/etc/php.ini

To find:

session.save_path = "/var/cpanel/php/sessions/ea-php56"

And change to:

session.save_path = "/tmp"

That used to be on the old EasyApache3 in the PHP configuration /usr/local/lib/php.ini.

After that, the warning did not appear.

See also:
Migration from EasyApache 3 to EasyApache 4

The warning solution “The MaxMind Geolite databases will soon be deprecated” in Cpanel

Once launched a server security check by clicking “Check Server Security” in “Main” – “Plugins” – “ConfigServer Security & Firewall” and saw a warning:

Firewall Check
CC_OLDGEOLITE option check
The MaxMind Geolite databases will soon be deprecated, disable CC_OLDGEOLITE to start using the new Geolite2 databases

This option determines which database to use, the old MaxMind Geolite or the new MaxMind Geolite2.
If the option “CC_OLDGEOLITE” is 1, which is in my case, then the old one is used, and if 0, then the new one.

To enable the use of a new one, open the CSF configuration for example in the text editor nano:

nano /etc/csf/csf.conf

Find the option CC_OLDGEOLITE and change its value from 1 to 0:


In the nano editor, the Ctrl+X keys are used to exit, and y/n and Enter to save or discard the changes.

After the changes, restart CSF by clicking “Firewall Restart” in the menu “Main” – “Plugins” – “ConfigServer Security & Firewall”.

Configuring Cron Jobs in cPanel and WHM

Cron jobs are added separately for each user through the cPanel and WHM web interface, namely cPanel “Advanced” -> “Cron Jobs“.
Through the WHM panel “Home” -> “Server Configuration” -> “Configure cPanel Cron Jobs“.

But there are also system tasks that can not be seen through the panel.
They can be seen by connecting through SSH to the server and running the command from the root user:

crontab -e

or from another user via sudo:

sudo crontab -e

In the nano editor, the shortcut Ctrl+X is used to exit, and y/n to save or discard the changes.
The file itself with the tasks is located on the path /var/spool/cron/root

If an annoying report is sent to an e-mail when executing an assignment, you can hide the output of the task by adding the following code to the end of the command:

>/dev/null 2>&1

To restart the Cron service, use the command:

service crond restart

See also a similar article: Using and configuring CRON

How to start ClamAV scanning from the command line on the cPanel server

Here is an example of checking the public_html directory with the removal of infected files:

/usr/local/cpanel/3rdparty/bin/clamscan -ri --remove /home/user/public_html

Similarly, other directories are checked.

To start checking only the mail and public_html directory for all users:

/usr/local/cpanel/3rdparty/bin/clamscan -ri /home/*/mail
/usr/local/cpanel/3rdparty/bin/clamscan -ri /home/*/public_html

To update the anti-virus database, use the command:


See also my article:
Installing and using ClamAV antivirus software

How to restart services in cPanel

The services must be restarted through the WHM interface, by opening “Home” > “Restart Services”.

If the restart of the service through the WHM interface failed, then the script should be used:


If you are using IPv6 and the command was executed:

service network restart

That IPv6 does not work to solve the problem:

/etc/init.d/cpipv6 restart (for cPanel & WHM version 11.52 and earlier)
/usr/local/cpanel/scripts/restartsrv_cpipv6 (for cPanel & WHM version 54 and later)

In extreme cases, you can try to restart the service directly:

/etc/rc.d/init.d/service restart
systemctl restart service-name.service

See also:
Location of log files cPanel

Solution of the error “Using unique option prefix pass instead of password is deprecated …”

I noticed some errors coming to the root mail with the subject and the text:

Cron /usr/bin/test -x /usr/local/cpanel/scripts/update_db_cache && /usr/local/cpanel/scripts/update_db_cache
Warning: Using unique option prefix pass instead of password is deprecated and will be removed in a future release. Please use the full name instead.

The problem lies in the file ~ / .my.cnf, that is /root/.my.cnf in my case.

In which the parameter “pass” is obsolete and must be changed to a new “password”.

For example, that’s how it was when the error occurred:


Changed to password and the error disappeared:


See also:
Connecting to MySQL from localhost without entering a password