Would upping the logging level to info help? Disable servers? One by one?
1 Like
Upping log level possibly. But, I still think nothing is wrong with mariadb. I think something else is wrong, and we’re all trying to troubleshoot the wrong thing.
Disabling servers no. Domain owner users cannot stop Mariadb. This is a root-level action, so nothing in Virtualmin domains can cause it (if it is being stopped, rather than stopping on its own for some reason that isn’t showing up in the logs).
that’s what i looking for it
if this help my problem why not
how can i do that ( starting Mariadb in safe mode)
This may help
I am in agrement here.
I am not saying it is MariaDB and neither suggesting it has anything to do with Virtualmin.
I am still saying it is the code in the website at fault.
The idea of taking everything to the state at which it originally worked is a good place to start. (even if it means an older version of MariaDB). so good to be reassured that Virtualmin doesn’t care what version is on the box.
Something is killing MariaDB (or it is falling over due to some action in the code that is using it) that can only be due to the code in the website, as nothing else is using MariaDB.
MariaDB may have had a bug/issue in version 5 that was fixed in later versions.
The log that I see as most hopeful is the PHP log for the site. All that we have from the MariaDB log is that it started OK and it was then stopped just after some InnoDB foreign key indexing issue. (What FK on what table would be nice to know)
So Submit a detailed bug report to https://jira.mariadb.org/ → did anyone?
I think it is pretty clear here mariadb.service: control process exited, code=exited status=1
and mariadb.service failed.
The mariadb-prepare-db-dir: If this is not the case, make sure the /var/lib/mysql is empty before running mariadb-prepare-db-dir.
suggests to me that the internal InnoDB process is trying to do a file creation step but for some reason cannot (perhaps a bug in MariasDB that was later fixed?)
BTW " mariadb-prepare-db-dir" is an internal process managed by MariaDB why is it starting and why is it failing?
I wouldn’t expect it to be.
but maybe it should be before that mariadb-prepare-db-dir is run. I am pretty certain this is an internal process called when MariaDB initialises or starts.
I would leave alone for now (or at least take a backup of it before such a drastic step)
Do you have backups of your databases? If you don’t, do not touch those files in that folder.
I’d suggest double checking disk quotas / space for each of your virtualmin virtual servers.
Why not copy the directory somewhere else delete the contents of the original and try a restart ? If it fails just copy the original files back. As centos is near the point that no one should be using it, it may be worthwhile changing to an OS that is more current and trying again
Since we are grasping at straws at this point, what happens if you try and start it on the command line. There seems to be one option that actually tells it to stop after starting which seems strange or I’m reading it wrong.
• --no-auto-restart, --nowatch, --no-watch
Exit after starting mysqld.
So try :
/usr/bin/mysqld_safe
I think I will do this after a do backup of databases
[root@xxxx~]# /usr/bin/mysqld_safe
231016 16:52:23 mysqld_safe Logging to ‘/var/log/mariadb/mariadb.log’.
231016 16:52:23 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
[root@xxxx~]#
OK. Did it stay running?
ps aux |grep mariadb
[root@xxxx~]# ps aux |grep mariadb
root 2822 0.0 0.0 112808 976 pts/0 S+ 16:55 0:00 grep --color=auto mariadb
[root@xxxx~]#
OK. So, no. I’m trying to find a way to start it from the command line in debug, but so far, no luck. 
i want an expert with those stuff to hire him to fix my problem
Understood. One last thing I’d try is to up the log level to info. I don’t know where it is on your system. On Debian 11 it seems to be:
root@main:/etc/mysql# grep -ir log
mariadb.conf.d/50-mysqld_safe.cnf:# SyslogLevel = err
No such file or directory
If you are considering this move I would avoid Centos altogether.
Because the requested SYSTEM INFORMATION was missing at the first post, I missed the fact it was Centos and not even v.8.
Anyway it seems to be a Centos related issue to do with package updates in both MySQL and MariaDB.https://www.dark-hamster.com/database/how-to-solve-error-message-database-mariadb-is-probably-initialized-in-var-lib-mysql-already-nothing-is-done/