I trying to set up master replication server. When I try to start/restart the server after added log-bin directory as following in my.cnf,
log-bin = /var/log/mysql/mysql-bin.log
the server is not starting up.
MySQL status
mysqld.service - MySQL Server
Loaded: loaded (/etc/systemd/system/mysqld.service; enabled)
Active: inactive (dead) since Mon, 13 Jul 2015 17:46:47 +0800; 1s ago
Process: 14145 ExecStart=/usr/bin/mysqld_safe --defaults-file=/etc/my.cnf --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock (code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/mysqld.service
But after I changed the log-bin as following (without folder path)
log-bin = mysql-bin.log
the server is running successfully.
MySQL status
mysqld.service - MySQL Server
Loaded: loaded (/etc/systemd/system/mysqld.service; enabled)
Active: active (running) since Mon, 13 Jul 2015 17:47:43 +0800; 2s ago
Main PID: 15272 (mysqld_safe)
CGroup: name=systemd:/system/mysqld.service
├ 15272 /bin/sh /usr/bin/mysqld_safe --defaults-file=/etc/my.cnf --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysq...
└ 15615 /usr/libexec/mysqld --defaults-file=/etc/my.cnf --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/...
Update
From mysqld.log :
/var/log/mysql/mysql-bin.index' not found (Errcode: 2)
But my mysql-bin.index by default at
/var/lib/mysql/mysql-bin.index
Could anyone please help me out as I just start to learn master-slave replication? Do I need to create a folder name mysql and change the permission to mysql and put in log directory or how I can make sure it locates my mysql-bin.index file correctly?
Finally I have found the solution. Not sure whether I did it in a right way.
After searched about (Errcode: 2), found that it is indicate that the file or directory does not exist. So I have created the folder named as mysql and added in log directory (Logged in as root user). When I try to restart the server, it gives me another error:
/var/log/mysql/mysql-bin.index' not found (Errcode: 13)
Errcode: 13 indicates permission denied. So I have change the ownership from root to mysql :
chown -R mysql:mysql /var/log/mysql
I restart the server and it runs successfully.
If there is an error in path access related to data and logs of mysql it will call the default /var/lib/mysql and /var/log/mysql. To ovveride mysql log file path do the following.
create new path
make the path with ownership of mysql user
example - sudo shown -R mysql:mysql /mnt/mysql/logs
pass the path to apparmor to read this directory.
file location - /etc/apparmor.d/usr.sbin.mysqld
content
# Allow log file access
/mnt/mysql/logs/ r,
/mnt/mysql/logs/** rw,
Note: if apparmor has not correct path then it will give issue of permission that confuses with simple chown and chmod
Related
I have a problem to move the default datadir of Maria DB to another partition, it appears to be very common but i tried everything I can without luck.
Mysql is installed as Mariadb 10.1.26 with the default debian package (apt-get install mysql-server) on a Debian 9.1 (stretch) server, mysqld -v returns mysqld 10.1.26-MariaDB-0+deb9u1
Default_mysql_datadir : /var/lib/mysql
New_mysql_datadir : /home/mysql
/var/lib/mysql is mounted to "/" (/dev/md3)
/home/mysql is mounted to "/home" (/dev/md4)
What I've tried
# systemctl stop mysql
# mv /var/lib/mysql /home
Change datadir in /etc/mysql/my.cnf
# datadir = /home/mysql
Check if the rights/permissions are ok
# chown -R mysql.mysql /home/mysql
apparmor is NOT installed nor running on the system though the /etc/apparmor.d/usr.sbin.mysqld file is existing with the following rules :
/home/mysql/ r,
/home/mysql/** rwk,
I even tried to create and empty /var/lib/mysq folder refering to this bug
But when I start I always get the same error :
# systemctl start mysql
[Warning] Can't create test file /home/mysql/<user>.lower-test
#007/usr/sbin/mysqld: Can't change dir to '/home/mysql/' (Errcode: 13 "Permission denied") 2017-09-07 0:16:59 140119808397888 [ERROR] Aborting
mariadb.service: Main process exited, code=exited, status=1/FAILURE
Failed to start MariaDB database server.
mariadb.service: Unit entered failed state.
mariadb.service: Failed with result 'exit-code'.
Any suggestion ?
Thanks
Services started by Systemd have additional filesystem restrictions imposed by systemd.
It should be possible to provide values to systemd [Service] directives ProtectHome= and/or ProtectSystem= and/or ReadWritePaths= to resolve this issue.
I have similar problem:
When I start the mysql services a message is shown:
Job for mariadb.service failed because the control process exited with error code.
See "systemctl status mariadb.service" and "journalctl -xe" for details.
if I change the datadir from /etc/mysql/my.cnf again as default; np
Console says
[root#ip-172-31-18-2 mysql]# service mysqld start
Starting mysqld (via systemctl): Job for mysqld.service failed because the control process exited with an error code. See "systemctl status mysqld.service" and "journalctl -xe" for details.
mysqld.service
[root#ip-172-31-18-2 mysql]# systemctl status mysqld.service
● mysqld.service - SYSV: MySQL database server.
Loaded: loaded (/etc/rc.d/init.d/mysqld)
Active: failed (Result: exit-code) since Sat 2017-02-18 20:59:17 IST; 36s ago
Docs: man:systemd-sysv-generator(8)
Process: 9925 ExecStart=/etc/rc.d/init.d/mysqld start (code=exited, status=1/FAILURE)
Feb 18 20:59:16 ip-172-31-18-2.ap-southeast-1.compute.internal systemd[1]: Starting SYSV: MySQL database server....
Feb 18 20:59:17 ip-172-31-18-2.ap-southeast-1.compute.internal mysqld[9925]: MySQL Daemon failed to start.
Feb 18 20:59:17 ip-172-31-18-2.ap-southeast-1.compute.internal mysqld[9925]: Starting mysqld: [FAILED]
Feb 18 20:59:17 ip-172-31-18-2.ap-southeast-1.compute.internal systemd[1]: mysqld.service: control process exited, code=exited status=1
Feb 18 20:59:17 ip-172-31-18-2.ap-southeast-1.compute.internal systemd[1]: Failed to start SYSV: MySQL database server..
Feb 18 20:59:17 ip-172-31-18-2.ap-southeast-1.compute.internal systemd[1]: Unit mysqld.service entered failed state.
Feb 18 20:59:17 ip-172-31-18-2.ap-southeast-1.compute.internal systemd[1]: mysqld.service failed.
What I have tried until now:
mysqld_safe --defaults-file=/etc/my.cf
chown -R mysql:mysql /var/lib/mysql
/etc/init.d/mysqld start
/etc/init.d/mysqld stop
systemctl restart systemd-logind
rebooted the server
Still no luck.
my.cnf file
# For advice on how to change settings please see
# http://dev.mysql.com/doc/refman/5.7/en/server-configuration-defaults.html
[mysqld]
#
# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for a dedicated server, else 10%.
# innodb_buffer_pool_size = 128M
#
# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin
#
# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
# join_buffer_size = 128M
# sort_buffer_size = 2M
# read_rnd_buffer_size = 2M
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
This amazingly worked.
/etc/init.d/mysql stop
service mysql stop
killall -KILL mysql mysqld_safe mysqld
/etc/init.d/mysql start
service mysql start
I had the same error, the problem was because I no longer had disk space.
to check the space run this:
$ df -h
Then delete some files that you didn't need.
After this commands:
service mysql start
systemctl status mysql.service
mysql -u root -p
After entering with the root password verify that the mysql service was active
I met this problem today, and fix it with bellowed steps.
1, Check the log file /var/log/mysqld.log
tail -f /var/log/mysqld.log
2017-03-14T07:06:53.374603Z 0 [ERROR] /usr/sbin/mysqld: Can't create/write to file '/var/run/mysqld/mysqld.pid' (Errcode: 2 - No such file or directory)
2017-03-14T07:06:53.374614Z 0 [ERROR] Can't start server: can't create PID file: No such file or directory
The log says that there isn't a file or directory /var/run/mysqld/mysqld.pid
2, Create the directory /var/run/mysqld
mkdir -p /var/run/mysqld/
3, Start the mysqld again service mysqld start, but still fail, check the log again /var/log/mysqld.log
2017-03-14T07:14:22.967667Z 0 [ERROR] /usr/sbin/mysqld: Can't create/write to file '/var/run/mysqld/mysqld.pid' (Errcode: 13 - Permission denied)
2017-03-14T07:14:22.967678Z 0 [ERROR] Can't start server: can't create PID file: Permission denied
It saids permission denied.
4, Grant the permission to mysql
chown mysql.mysql /var/run/mysqld/
5, Restart the mysqld
# service mysqld restart
Restarting mysqld (via systemctl): [ OK ]
These are the steps I took to correct this:
Back up your my.cnf file in /etc/mysql and remove or rename it
sudo mv /etc/mysql/my.cnf /etc/mysql/my.cnf.bak
Remove the folder /etc/mysql/mysql.conf.d/ using
sudo rm -r /etc/mysql/mysql.conf.d/
Verify you don't have a my.cnf file stashed somewhere else (I did in my home dir!) or in /etc/alternatives/my.cnf use
sudo find / -name my.cnf
Now reinstall every thing
sudo apt purge mysql-server mysql-server-5.7 mysql-server-core-5.7
sudo apt install mysql-server
In case your syslog shows an error like "mysqld: Can't read dir of '/etc/mysql/conf.d/'" create a symbolic link:
sudo ln -s /etc/mysql/mysql.conf.d /etc/mysql/conf.d
Then the service should be able to start with sudo service mysql start.
I hope it work
In my particular case, the error was appearing due to missing /var/log/mysql with mysql-server package 5.7.21-1 on Debian-based Linux distro. Having ran strace and sudo /usr/sbin/mysqld --daemonize --pid-file=/run/mysqld/mysqld.pid ( which is what the systemd service actually runs), it became apparent that the issue was due to this:
2019-01-01T09:09:22.102568Z 0 [ERROR] Could not open file '/var/log/mysql/error.log' for error logging: No such file or directory
I've recently removed contents of several directories in /var/log so it was no surprise. The solution was to create the directory and make it owned by mysql user as in
$ sudo mkdir /var/log/mysql
$ sudo chown -R mysql:mysql /var/log/mysql
Having done that I've happily logged in via sudo mysql -u root and greeted with the old and familiar mysql> prompt
if your problem not fix, you can try check more problem.
maybe mysql crash , like this :
you can check log in
sudo cat /var/log/mysql/error.log
or you check
sudo ls /var/crash
try
sudo chown mysql:mysql -R /var/lib/mysql
then start your mysql service
systemctl start mysqld
the issue is with the "/etc/mysql/my.cnf". this file must be modified by other libraries that you installed. this is how it originally should look like:
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License, version 2.0,
# as published by the Free Software Foundation.
#
# This program is also distributed with certain software (including
# but not limited to OpenSSL) that is licensed under separate terms,
# as designated in a particular file or component or in included license
# documentation. The authors of MySQL hereby grant you an additional
# permission to link the program and your derivative works with the
# separately licensed software that they have included with MySQL.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License, version 2.0, for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
#
# The MySQL Server configuration file.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html
# * IMPORTANT: Additional settings that can override those from this file!
# The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/
I was also facing same issue .
root#*******:/root >mysql -uroot -password
mysql: [Warning] Using a password on the command line interface can be
insecure. ERROR 2002 (HY000): Can't connect to local MySQL server
through socket '/var/lib/mysql/mysql.sock' (2)
I found ROOT FS was also full and then I killed below lock session .
root#**********:/var/lib/mysql >ls -ltr
total 0
-rw------- 1 mysql mysql 0 Sep 9 06:41 mysql.sock.lock
Finally Issue solved .
open my.cnf and copy the log-error path
then check the permission for the copied log file using
$ ls -l /var/log/mysql.log
if any log file permission may changed from mysql:mysql, please change the file permission to
$ chown -R mysql:mysql /var/log/mysql.log
then restart the mysql server
$ service mysql restart || systemctl restart mysqld
note: this kind of errors formed by the permission issues. all the mysql service start commands using the log file for writing the status of mysql. If the permission has been changed, the service can't be write anything into the log files. If it happens it will stopped to run the service
remove any command of "secure_file_priv" in /etc/mysql/my.cnf and restart mysql.
If you want to use a file in mysql, copy those files to the main folder.
The main folder is obtained this way : SHOW VARIABLES LIKE "secure_file_priv";
You can purge all mysql-related packages and reinstall them with the following commands:
PACKAGES="mysql-server mysql-community-server mysql-community-server-core mysql-client mysql-client mysql-community-client mysql-community-client-core mysql-common mysql-community-client-plugins php-mysql"
apt purge $PACKAGES
echo "any remaining installed packages:"
dpkg -l|grep ii|grep mysql
apt install --reinstall mysql-common
apt install $PACKAGES
If there are any remaining packages (apart from mysql-core), add those to your list
Backup your config or data and reinstall mysql
sudo apt remove --purge mysql-server
sudo apt purge mysql-server
sudo apt autoremove
sudo apt autoclean
sudo apt remove dbconfig-mysql
sudo apt-get remove --purge mysql* -y
sudo apt-get autoremove -y
sudo apt-get autoclean
Then install it again.
That works here.
i have got the same "systemctl status mysql.service" and "journalctl -xe" for details. ERROR.
after repeated deinstallation and installation does not work at all.
but this one work well> https://linuxtut.com/en/5a5b0f46620ae1b27b10/
you just need to remove everything from my.cnf file except [mysqld] and start the server. this really work. but you might not have the password for root in that case skip-grant-tables and restart server in safe mode and use mysql and
update mysql.user set authentication_string=null where user='root' and then can alter user 'root'#'localhost' identified by 'your_$$new_99pwd#';
then login to secure mode and then you can create new user.
Also don't forget to check on your docker containers, for me it was my docker has mysql running on the background.
Connect to the server using SSH.
Stop the affected MySQL service and the service plesk-web-socket to prevent it from attempting to start MySQL:
service mysql stop || service mariadb stop && service plesk-web-socket stop
Back up all the MySQL data storage files. By default, they are located in the directory /var/lib/mysql/.
For example:
cp -a /var/lib/mysql /root/mysql_backup
Add the parameter innodb_force_recovery to the section [mysqld] of the MySQL configuration file. This option allows starting MySQL service in the recovery mode and try creating dumps of databases.
For example:
vi /etc/my.cnf
[mysqld]
innodb_force_recovery = 2
Start the MySQL service.
after having tested several solutions without success, the one that finally worked is the following:
you can load the default configuration of your apache server
sudo a2ensite 000-default.conf
sudo a2dissite my.conf
systemctl reload apache2
then reload the configuration for your website
sudo a2ensite my.conf
sudo a2dissite 000-default.conf
systemctl reload apache2
I had the same issue and after hours the solution was for me:
Open this file nano /etc/mysql/my.cnf
#I use mysql service if you use mysqld service, type mysqld instead of mysql
[mysql]
innodb_force_recovery = 1
Had the same problem. Solved as given below.
Use command :
sudo tail -f /var/log/messages|grep -i mysql
to check if SELinux policy is causing the issue. If so, first check if SELinux policy is enabled using command #sestatus. If it shows enabled, then disable it.
To disable:
# vi /etc/sysconfig/selinux
change 'SELINUX=enforcing' to 'SELINUX=disabled'
restart linux
check with sestatus and it should show "disabled"
Uninstall and reinstall mysql. It should be working.
This is my first post here, so I hope I do everything right and don't forget any important info. I'm glad for any hints, because I'm running out of ideas (if I ever had any ;)).
I am (or was) running owncloud on Raspbian Jessie (so I guess basically Debian). Suddenly owncloud stopped working. The nginx error points towards php5-fpm, further searches gave this error:
exception 'Doctrine\DBAL\DBALException' with message 'Failed to connect to the database: An exception occured in driver: SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)' in /var/www/owncloud/lib/private/db/connection.php:54
So it looks like a mysql error, and /var/run/mysqld/ is actually empty.
Following these posts 1 and
2, I tried
sudo find / -type s
resulting in this output:
/run/php5-fpm.sock
/run/fail2ban/fail2ban.sock
/run/thd.socket
/run/dhcpcd.unpriv.sock
/run/dhcpcd.sock
/run/dbus/system_bus_socket
/run/avahi-daemon/socket
/run/udev/control
/run/systemd/journal/syslog
/run/systemd/journal/socket
/run/systemd/journal/stdout
/run/systemd/journal/dev-log
/run/systemd/shutdownd
/run/systemd/private
/run/systemd/notify
find: `/proc/30933/task/30933/fd/5': No such file or directory
find: `/proc/30933/task/30933/fdinfo/5': No such file or directory
find: `/proc/30933/fd/5': No such file or directory
find: `/proc/30933/fdinfo/5': No such file or directory
In the processes with top on the other hand, mysqld and mysqld_safe show up.
mysql-client, mysql-server and php5-mysql are installed and updated to the latest versions.
I also had a look at
/etc/mysql/my.cnf
/etc/mysql/debian.cnf
both show /var/run/mysqld/mysqld.sock as socket...
/var/lib/mysql/my.cnf
mentioned here does not exist.
Additionally, it seems that I can't connect to mysql through
mysql -u user -p
at least it results in the Error 2002 as well.
Finally, I tried stopping and starting the mysql service. This resulted in the following output of
systemctl status mysql.service
mysql.service - LSB: Start and stop the mysql database server daemon
Loaded: loaded (/etc/init.d/mysql)
Active: failed (Result: exit-code) since So 2016-04-10 11:54:23 CEST; 23s ago
Process: 9777 ExecStop=/etc/init.d/mysql stop (code=exited, status=0/SUCCESS)
Process: 12878 ExecStart=/etc/init.d/mysql start (code=exited, status=1/FAILURE)
So I'm kind of lost what is going on, the problem occurs since some updates a few days ago. While writing this post, I went through all the steps again, just to be safe. At one point, I had a short glimpse at my owncloud instance in the browser, but then it was gone again. So I appreciate any help/hints!!!
Thank you very much!!!
I faced the issue: Can't connect to '/var/run/mysqld/mysqld.sock'. The problem was that mysql service was not started after installation. Once I run the following command, then it worked properly:
systemctl start mysql.service
mysql -u root -p
1.Activate log in .my.cnf
log = /var/log/mysql/mysql.log
Error logging goes to syslog. This is a Debian improvement :)
Here you can see queries with especially long duration
log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 2
log-queries-not-using-indexes
$ ls -l /var/run/ | grep mysqld
$ ps -ef |grep mysql
tail -f /var/log/mysql/mysql.log
restart mysql
(option) delete socket & restart mysql
I'm trying to move the data directory of mysql, here are my steps:
use show variables like 'datadir' to know my datadir is /var/lib/mysql/
cd /var/lib/mysql/
# mv * /home/elderry/db/
gvim /etc/mysql/my.cnf
Add this line in [mysqld] section:
datadir = /home/elderry/db/
# systemctl start mysqld
Job for mysqld.service failed. See 'systemctl status mysqld.service' and 'journalctl -xn' for details.
Then I tried: systemctl status mysqld.service
Result:
mysqld.service - MariaDB database server
Loaded: loaded (/usr/lib/systemd/system/mysqld.service; disabled)
Active: activating (start-post) (Result: exit-code) since Tue 2013-07-30 14:31:53 CST; 13s ago
Process: 14174 ExecStart=/usr/bin/mysqld --pid-file=/run/mysqld/mysqld.pid (code=exited, status=1/FAILURE)
Control: 14175 (mysqld-post)
CGroup: name=systemd:/system/mysqld.service
└─control
├─14175 /bin/sh /usr/bin/mysqld-post
└─14293 sleep 1
Jul 30 14:31:53 Kanone mysqld[14174]: 130730 14:31:53 [Warning] Can't create test file /home/elderry/db/Kanone.lower-test
Jul 30 14:31:53 Kanone mysqld[14174]: [71B blob data]
Jul 30 14:31:53 Kanone mysqld[14174]: 130730 14:31:53 [ERROR] Aborting
Jul 30 14:31:53 Kanone mysqld[14174]: 130730 14:31:53 [Note] /usr/bin/mysqld: Shutdown complete
Jul 30 14:31:53 Kanone systemd[1]: mysqld.service: main process exited, code=exited, status=1/FAILURE
If I want to start mysql manually: mysql -u root -p
output:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/run/mysqld/mysqld.sock' (2)
What shoud I do for now?
It seems you moved the datadir to your home directory. I think that when you start mysqld via your service manager (in your case systemd) it will be started as an unprivileged user (most likely mysql). I strongly doubt that this user has privileges to access the homedir of the user elderry.
So the solution would either be moving your datadir to a more suitable location like /var/lib/mysql and chown this directory to the user under which mysql runs. Or that you give the mysql user privileges that he can acces the homedir of elderry.
When installing MariaDB, it creates user and group mysql automatically that own all data files, so if you move data dir, make sure that all folder, subfoler, files in new data directory are owned by user mysql and group mysql.
Also check if your partition is not full, which was my case.
For an unknown reason, moving the data to another partition did not work either.
So for a quick fix, instead of messing with llvm or gparted, I reduced my /swapfile size.
Server shutdown from power failure.
Mysql will not start now.
Disk is not full.
Syslog is below
Oct 11 15:03:31 joe mysqld_safe[24757]: started
Oct 11 15:03:31 joe mysqld[24760]: 101011 15:03:31 InnoDB: Operating system error number 13 in a file operation.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: The error means mysqld does not have the access rights to
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: the directory.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: File name ./ibdata1
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: File operation call: 'create'.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: Cannot continue operation.
If you are using ubuntu or apparmor you should permit this change in apparmor.
Edit /etc/apparmor.d/usr.sbin.mysqld and change /var/lib/mysql with the new DATADIR.
It should work.
Error:
101130 14:42:51 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
101130 18:07:58 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
101130 18:07:58 InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name ./ibdata1
InnoDB: File operation call: 'open'.
InnoDB: Cannot continue operation.
Solution SeLinux SeLinux security:
[root#localhost ~]# service mysqld restart
Deteniendo mysqld: [ OK ]
Iniciando mysqld: [ FALLÓ ]
[root#localhost ~]# restorecon -R /var/lib/mysql/
[root#localhost ~]# service mysqld restart
Deteniendo mysqld: [ OK ]
Iniciando mysqld: [ OK ]
[root#localhost ~]#
please check this:
chown -R mysql:mysql /var/lib/mysql
The file is not corrupt. You can find out the source of these errors with 'perror'. i.e.
toaster:~ morgo$ perror 13
OS error code 13: Permission denied
InnoDB has corruption detection (page checksums) and would happily tell you if that were the problem.
Either the directory permissions have changed, or your my.cnf file has been hosed, and it's trying to recreate data files somewhere else.
For me, restoring the security context (selinux) did the trick
restorecon -R /var/lib/mysql/
In short, (especially on RHEL/CentOS/Fedora) try
getenforce
if it replies with Enforcing you have SELinux up and running. Temporarily deactivate it with setenforce 0 and see if MariaDB starts now! Rather common, especially on RHEL/CentOS/Fedora.
There's more about this further down, as well as in this official article.
In general
There are more things in a UNIX environment that might prevent file access, than just user access rights.
Security modules like SELinux (see above) or AppArmor (as Dan mentioned) could disallow it
Access Control Lists (ACL) could be specifically set, for the required files/directories
Any of the parent folders could be owned by another user, and have no x (="dir access") set for others
Additionally there could be other unexpected factors, like ...
The mysql datadir being set to a place, where mysql doesn't have permissions (see /etc/my.cnf)
Mysql could (strangely) be running as a different user, or the file could be simply owned by someone else
Just to mention a view things off the top of my head (feel free to edit/add to this answer btw).
In the case, SELinux is "the problem"
For a permanent solution, you could try to restore the appropriate security context, ...
restorecon -R /var/lib/mysql/
... or just deactivate SELinux (but think about this one a little bit before doing so), by editing the config (typically in /etc/selinux/config) and setting SELINUX=disabled as suggested in following article.
Here the official help page from mariadb.com: What to do if MariaDB doesn't start
And here something from redhat.com: MariaDB Changing Database Location
Obviously those are applicable to MySQL just the same way.
I had exactly the same problem on my CentOS box. After moving mysql data directory around I couldn't start the service anymore, even as I had copied the files with the same owner and permissions.
I had a problem with the SELinux security context. If you run your CentOS stock it has good chance to be enabled and won't let do what you want with MySQL. To fix this :
First compare the old dir and new dir using
ls -Z /var/lib/mysql
and
ls -Z /new/mysql/dir
If you see any difference it's likely to be your problem.
To modify this :
chcon -R --type=mysql_db_t /new/mysql/dir
The -R switch is for recursion. If you only need to change one file you can omit it.
If your context is different than mine(maybe a different distro), use the one indicated by the output of the first (it should be the 3rd field of the SELinux stuff)
ls -Z /var/lib/mysql
I had the same problem and fix by below steps
Working directory /var/lib/mysql
Earlier /var/lib/mysql was owned by some unknown user
Changed it to mysql
mysql]# chown -R mysql:mysql *
mysql]# service mariadb start
Redirecting to /bin/systemctl start mariadb.service
Works like a charm
I had exactly the same problem on my CentOS box. After moving mysql data directory around I couldn't start the service anymore, even as I had copied the files with the same owner and permissions.
I had a problem with the SELinux security context. If you run your CentOS stock it has good chance to be enabled and won't let do what you want with MySQL. To fix this :
First compare the old dir and new dir using
ls -Z /var/lib/mysql
and
ls -Z /new/mysql/dir
If you see any difference it's likely to be your problem.
To modify this :
chcon -R --type=mysql_db_t /new/mysql/dir
The -R switch is for recursion. If you only need to change one file you can omit it.
When this popped up for me, I found the answer in the /etc/mysql/my.cnf configuration file. The datadir line did not point to the /var/lib/mysql directory (where the databases are). Once I put this path in, the server restarted no problem.
If you use SEL Linux
Intall semanage
yum whatprovides /usr/sbin/semanage you get policycoreutils-python-2.5-22.el7.x86_64
See mysqld security context
After installation yum install policycoreutils-python you can just look what different security context mysqld has.
semanage fcontext -l | grep mysqld
/etc/mysql(/.*)? all files system_u:object_r:mysqld_etc_t:s0
/etc/my\.cnf\.d(/.*)? all files system_u:object_r:mysqld_etc_t:s0
/var/log/mysql.* regular file system_u:object_r:mysqld_log_t:s0
/var/lib/mysql(-files|-keyring)?(/.*)? all files system_u:object_r:mysqld_db_t:s0
/var/run/mysqld(/.*)? all files system_u:object_r:mysqld_var_run_t:s0
/var/log/mariadb(/.*)? all file system_u:object_r:mysqld_log_t:s0
/var/run/mariadb(/.*)? all files system_u:object_r:mysqld_var_run_t:s0
/usr/sbin/mysqld(-max)? regular file system_u:object_r:mysqld_exec_t:s0
/var/run/mysqld/mysqlmanager.* regular file system_u:object_r:mysqlmanagerd_var_run_t:s0
/usr/lib/systemd/system/mysqld.* regular file system_u:object_r:mysqld_unit_file_t:s0
/usr/lib/systemd/system/mariadb.* regular file system_u:object_r:mysqld_unit_file_t:s0
/etc/my\.cnf regular file system_u:object_r:mysqld_etc_t:s0
/root/\.my\.cnf regular file system_u:object_r:mysqld_home_t:s0
/usr/sbin/ndbd regular file system_u:object_r:mysqld_exec_t:s0
/usr/libexec/mysqld regular file system_u:object_r:mysqld_exec_t:s0
/usr/bin/mysqld_safe regular file system_u:object_r:mysqld_safe_exec_t:s0
/usr/bin/mysql_upgrade regular file system_u:object_r:mysqld_exec_t:s0
/etc/rc\.d/init\.d/mysqld regular file system_u:object_r:mysqld_initrc_exec_t:s0
/var/lib/mysql/mysql\.sock socket system_u:object_r:mysqld_var_run_t:s0
/usr/libexec/mysqld_safe-scl-helper regular file system_u:object_r:mysqld_safe_exec_t:s0
/home/[^/]+/\.my\.cnf regular file unconfined_u:object_r:mysqld_home_t:s0
Here you see all context for mysqld a short list with explanation
mysqld_etc_t - config files
mysqld_db_t - data db files
mysqld_log_t - log files
mysqld_exec_t - execution files
So if you have the wrong security context on your files you get a permission denied (error 13)
Solution
chcon -R -u system_u -t mysqld_db_t /var/lib/mysql
But check the "normal" permissions, too. I had this problem with centos. You have to systemctl restart mysql for the changes.
In my siuation is Selinux's problem. And the
chcon -R --type=mysql_db_t /new/mysql/dir comes error:
chcon: failed to change context of /new/mysql/dir to root:object_r:mysql_db_t: Invalid argument.
So i use the command：chcon -R root:object_r:mysqld_db_t /new/mysql/dir.
If you have this problem on a Synology NAS you can fix it by following the advice of the Synology support team:
Dear User,
This has been confirmed as a known issue and we will try to fix this issue in further MariaDB release. Sorry for your inconvenience.
Here is the workaround:
Please try to telnet to your DS with "root" account and password (same as admin's)
run the command "echo 1 > /var/services/mysql/VERSION"
open MariaDB package from DSM will trigger update again
type in the DB password and click Update will fix this issue
More info: Synology forum
I had the same problem.
Did alot of research and found out this solution.
You need to run this command on ibdata1
sudo shadowprotect -u root | root
I dont know what this does.. but it worked for me.
Good luck.