• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:
    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Issue mariadb restarts every day at 8.30 and I don't know why -> (ERROR mysqld got signal 11)

scsjcm

scsjcm

New Pleskian
Server operating system version
Debian 11.6
Plesk version and microupdate number
Plesk Obsidian Versión 18.0.50 Actualización 2, última actualización el 15/Feb/2023 07:39
Hello everyone,
It may not be the best place, I apologize in advance if I disturb someone :)

A couple of months ago I'm going crazy with a reboot that happens every day at 8.30 - 9.30 and I can't find it.
I have checked the crons, and I have not found any task that makes the mariadb restart and gives me "ERROR mysqld got signal 11"
I don't see anything in the log that indicates the origin of the error, and I think it's not due to any memory problem.

What I have seen is that at this time some process starts that I don't know where it comes from that does a "SHOW TABLE STATUS FROM" of all the databases... this process takes approx 30-40 minutes (depending on the system load)... I have on server about 2500 databases with about 150 tables each.

It seems to me that this process is executed somehow and checks all the databases to confirm that they are ok before doing the XXXXXX process that ends up restarting the server with the error "ERROR mysqld got signal 11"

I have not been able to see who starts or how this process starts, and I think that something in PLESK or MARIADB is starting and ends with the error.
 
ChristophRo said:
could by a backup process that dumps mysql databases.
i've seen such things to cause crashes of the mysql process, if there are some irregularities/corruptions in one of the databases.
Click to expand...
thanks for your reply
i investigate and i think is something about task-script.php inside DailyMaintainance i try to dissable this script
 
scsjcm said:
i investigate and i think is something about task-script.php inside DailyMaintainance i try to dissable this script
Click to expand...
Better check /var/log/messages for messages on corrupt database tables. Very likely a crash is due to such.
 
You can also try to dump/backup the mysql databases manually and see if you can reproduce the crash - and if yes, on which database it happens.
The following script should be able to do that. (works out of the box on any Debian/Ubuntu system, though you may want to change the path for the dumps)

Code: 
#!/bin/bash

# config section
########################################
BACKUPDIR="/root/_mysqldumps"             #directory where the backups get saved
#
FILEEXT="sql.gz"                          #file extensions of the database dumps
EXCLUDEDB="performance_schema|phpmyadmin" #excluded databases from the backup
MYSQLDUMP="/usr/bin/mysqldump"            #path to mysqldump binary
CONFFILE="/etc/mysql/debian.cnf"          #debian mysql defaults file that contains login info
########################################

# get list of databases to backup
if [ "$1" ]
then
    # lookup requested mysql database
    ALLMYSQLDBS=$(mysql --defaults-file=$CONFFILE -N -B -e "SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME = '$1'")
else
    # get list of all mysql databases on the server
    ALLMYSQLDBS=$(mysql --defaults-file=$CONFFILE -N -B -e "SHOW DATABASES" | grep -vE $EXCLUDEDB)
fi

# dump each database and compress it ##
if [ "$ALLMYSQLDBS" ]
then
 for i in $ALLMYSQLDBS
  do
    TIMESTAMP=$(date +%Y%m%d%H%M)
    FILENAME="$TIMESTAMP.$FILEEXT"
    mkdir -p $BACKUPDIR/$i
    # -c        Use complete insert statements
    # -K        disable-keys, "ALTER TABLE tb_name DISABLE/ENABLE KEYS" will be put in the output
    # -Q        Quote table and column names with backticks (`)
    # -F        Flush logs file in server before starting dump
    # -e        extended-insert, Allows utilization of the new, much faster INSERT syntax.
    # -i        Dump Comments
    # -E        Dump Events
    # -R        Dump stored routines (functions and procedures).
    $MYSQLDUMP --defaults-file=$CONFFILE -c -K -Q -F -e -i -E -R --single-transaction --add-drop-table --no-autocommit $i | gzip -c  > $BACKUPDIR/$i/$FILENAME
    echo -e "\033[32mDatabase \033[33m$i\033[32m dumped into \033[33m$BACKUPDIR/$i/$FILENAME\033[0m"
 done
else
 echo -e "\033[31mDatabase [\033[33m$1\033[31m] does not exist!\033[0m"
 exit 1
fi
 
ChristophRo said:
You can also try to dump/backup the mysql databases manually and see if you can reproduce the crash - and if yes, on which database it happens.
The following script should be able to do that. (works out of the box on any Debian/Ubuntu system, though you may want to change the path for the dumps)

Code: 
#!/bin/bash

# config section
########################################
BACKUPDIR="/root/_mysqldumps"             #directory where the backups get saved
#
FILEEXT="sql.gz"                          #file extensions of the database dumps
EXCLUDEDB="performance_schema|phpmyadmin" #excluded databases from the backup
MYSQLDUMP="/usr/bin/mysqldump"            #path to mysqldump binary
CONFFILE="/etc/mysql/debian.cnf"          #debian mysql defaults file that contains login info
########################################

# get list of databases to backup
if [ "$1" ]
then
    # lookup requested mysql database
    ALLMYSQLDBS=$(mysql --defaults-file=$CONFFILE -N -B -e "SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME = '$1'")
else
    # get list of all mysql databases on the server
    ALLMYSQLDBS=$(mysql --defaults-file=$CONFFILE -N -B -e "SHOW DATABASES" | grep -vE $EXCLUDEDB)
fi

# dump each database and compress it ##
if [ "$ALLMYSQLDBS" ]
then
 for i in $ALLMYSQLDBS
  do
    TIMESTAMP=$(date +%Y%m%d%H%M)
    FILENAME="$TIMESTAMP.$FILEEXT"
    mkdir -p $BACKUPDIR/$i
    # -c        Use complete insert statements
    # -K        disable-keys, "ALTER TABLE tb_name DISABLE/ENABLE KEYS" will be put in the output
    # -Q        Quote table and column names with backticks (`)
    # -F        Flush logs file in server before starting dump
    # -e        extended-insert, Allows utilization of the new, much faster INSERT syntax.
    # -i        Dump Comments
    # -E        Dump Events
    # -R        Dump stored routines (functions and procedures).
    $MYSQLDUMP --defaults-file=$CONFFILE -c -K -Q -F -e -i -E -R --single-transaction --add-drop-table --no-autocommit $i | gzip -c  > $BACKUPDIR/$i/$FILENAME
    echo -e "\033[32mDatabase \033[33m$i\033[32m dumped into \033[33m$BACKUPDIR/$i/$FILENAME\033[0m"
 done
else
 echo -e "\033[31mDatabase [\033[33m$1\033[31m] does not exist!\033[0m"
 exit 1
fi
Click to expand...
great script :)
 
Peter Debik said:
Better check /var/log/messages for messages on corrupt database tables. Very likely a crash is due to such.
Click to expand...

I found 2 databases that contained corrupted information, and I think this was the reason.

There is a process that is launched in the morning around 8.00 that loops through all the databases with the command : "SHOW TABLE STATUS FROM databasename"
This process reached these databases, and caused the error and restarted the mysql service.

Today I checked it and everything worked OK. :)

By the way, can this process be disabled?
or change the time to run this loop to check all DB?
...because it consumes server resources at a time 8.00-9.00 when I have many clients connected.
 
Peter Debik said:
With
# grep -ri "/etc/cron.daily" /etc/cron.d/dailyjobs
you can see the daily maintenance time. I have never tried to change it myself, but I also do not see why this should not be possible to move it to a different time. A bit more can be seen here:
Click to expand...
perfect, i change hour dailyjobs execution :)

and you know if it is possible to disable the execution of the process... "SHOW TABLE STATUS FROM databasename" ... I think it's something inside plesk maintenance
 
I do not think these tasks should be touched at all. If developers put it there, better leave it there. It will have a purpose. These guys never do anything without good reason. I am not sure if it is possible to remove it, but removing it will for sure impact something, whatever that will be.
 
Peter Debik said:
I do not think these tasks should be touched at all. If developers put it there, better leave it there. It will have a purpose. These guys never do anything without good reason. I am not sure if it is possible to remove it, but removing it will for sure impact something, whatever that will be.
Click to expand...
thanks :)
 
Peter Debik said:
With
# grep -ri "/etc/cron.daily" /etc/cron.d/dailyjobs
you can see the daily maintenance time. I have never tried to change it myself, but I also do not see why this should not be possible to move it to a different time. A bit more can be seen here:
Click to expand...
I have changed the execution time, but the process has been executed at the same time as always.
I think this process is launched in some different way.
 
Peter Debik said:
Yes, probably it is. It may not be a Plesk process.
Click to expand...
I don't know if it's a coincidence....
but since the installation of the new version 18.0.51 of plesk (YESTERDAY UPDATE) ---> TODAY the "SHOW TABLE STATUS FROM databasename" process that looped in all the databases has not been carried out for me.

I think something happened in the last plesk update, and it didn't install completely correctly.... this should produce a "SELF-REPAIR DAILY SYSTEM PLESK"

Finally ... installed the new plesk update 18.0.51... it works fine.
 
scsjcm said:
I don't know if it's a coincidence....
but since the installation of the new version 18.0.51 of plesk (YESTERDAY UPDATE) ---> TODAY the "SHOW TABLE STATUS FROM databasename" process that looped in all the databases has not been carried out for me.

I think something happened in the last plesk update, and it didn't install completely correctly.... this should produce a "SELF-REPAIR DAILY SYSTEM PLESK"

Finally ... installed the new plesk update 18.0.51... it works fine.
Click to expand...
forget this post, today continue with check all tables :(
 
You must log in or register to reply here.

Similar threads

Talistech
Resolved Backups failing since a couple days: Unable to run the backup agent
Replies
1
Views
3K
Talistech
Talistech
F
Issue PHP suddenly crashes
Replies
12
Views
6K
FloLa
F
TimReeves
Resolved MariaDB Update to 10.11.7 via Plesk 18.0.60 on Debian 10
Replies
1
Views
848
TimReeves
TimReeves
C
Resolved Mariadb not working - DB query failed: SQLSTATE[HY000] [2002] No such file or directory
Replies
7
Views
2K
Crash79797
C
B
Issue High latency, unreliable performance & 522 errors on a Plesk server that ran fine for 6+ months
Replies
1
Views
242
Sebahat.hadzhi
Sebahat.hadzhi
Back
Top