MySQL. Bind na gnieździe unix: Odmowa dostępu

Nie można uruchomić mysql z:

130408 11:31:22 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
/usr/libexec/mysqld: Table 'plugin' is read only
130408 11:31:22 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
130408 11:31:22  InnoDB: Initializing buffer pool, size = 8.0M
130408 11:31:22  InnoDB: Completed initialization of buffer pool
130408 11:31:23  InnoDB: Started; log sequence number 0 19514977
130408 11:31:23 [ERROR] Can't start server : Bind on unix socket: Permission denied
130408 11:31:23 [ERROR] Do you already have another mysqld server running on socket: /var/lib/mysql/mysql.sock ?
130408 11:31:23 [ERROR] Aborting

130408 11:31:23  InnoDB: Starting shutdown...
130408 11:31:28  InnoDB: Shutdown completed; log sequence number 0 19514977
130408 11:31:28 [Note] /usr/libexec/mysqld: Shutdown complete
130408 11:31:28 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended

Inny mysql nie jest uruchomiony:

[root@triton667 etc]# ps ax | grep mysql
 9195 pts/1    S+     0:00 grep mysql

my.cnf:

    [mysqld]
    datadir=/var/lib/mysql
    socket=/var/lib/mysql/mysql.sock
    user=mysql
    tmpdir=/tmp
    # Disabling symbolic-links is recommended to prevent assorted security risks
    symbolic-links=0
    max_allowed_packet=256M

    [mysqld_safe]

    log-error=/var/log/mysqld.log
    pid-file=/var/run/mysqld/mysqld.pid

Uprawnienia do „/ tmp” i „/ var / lib / mysql” to 777 /

Jakieś sugestie?

UPD1 :

[root@triton667 etc]# mysql_upgrade
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
Running 'mysqlcheck with default connection arguments
mysqlcheck: Got error: 2002: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) trying to connect
FATAL ERROR: Upgrade failed

UPD2 : plugin.MYD, plugin.MYI i plugin.frm istnieją w / var / lib / mysql / mysql /.

Nic nie działa na porcie 3306.

mysql.sock nie istnieje. Próbowałem go utworzyć sam, ale po ponownym uruchomieniu został usunięty.

mount (all rw):

[root@triton667 mysql]# mount
/dev/md1 on / type ext4 (rw,noatime,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/md0 on /boot type ext2 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)

Ten problem pojawił się dzisiaj, gdy próbowałem sklonować moją witrynę do subdomeny.

1) Najpierw upewnij się, że usunąłeś istniejący plik gniazda za pomocą polecenia rm.

rm /var/lib/mysql/mysql.sock

2) Zabij wszystkie istniejące procesy MySQL za pomocą następującego polecenia.

service mysql stop

3) Bardzo ważne: Upewnij się, że uprawnienie do katalogu bazy danych MySQL w /var/lib/folderze powinno być mysql: root

chown -R mysql:root /var/lib/mysql

4) Dzięki powyższym informacjom powinieneś móc pomyślnie uruchomić MySQL, a plik gniazda powinien zostać pomyślnie utworzony w katalogu bazy danych.

service mysql start

Dzięki odpowiedzi @ Abhishek w połączeniu z wyjściem mysqld (nie mogę użyć /var/run/mysqld/mysqld.sock) udało mi się rozwiązać to za pomocą jednego polecenia:

chown -R mysql:root /var/run/mysqld

Następnie zaczyna się poprawnie:

root@***:~# service mysql start
df: Warning: cannot read table of mounted file systems: No such file or directory
[ ok ] Starting MySQL database server: mysqld ..
[info] Checking for tables which need an upgrade, are corrupt or were 
not closed cleanly..

Twój problem może być spowodowany przez dowolny warunek, który uniemożliwia demonowi MySQL zapisanie pliku gniazda do ścieżki /var/lib/mysql. Inne odpowiedzi, takie jak system plików tylko do odczytu lub nieprawidłowa własność katalogu, dotyczą różnych przyczyn, dla których MySQL może nie być w stanie zapisać do gniazda.

Innym możliwym powodem jest /var/lib/mysqlniepoprawny kontekst SELinux. Możesz zdiagnozować ten warunek, sprawdzając ostatnie odmowy SELCJI AVC po próbie uruchomienia demona MySQL:

ausearch -m avc --start recent

Jeśli SELinux odmawia dostępu do utworzenia pliku gniazda, zobaczysz następujący komunikat o błędzie:

time->Thu Feb  2 03:46:27 2017
type=SYSCALL msg=audit(1566106187.784:152): arch=c000004e syscall=49 success=no exit=-13 a0=4f a1=7ff3fd652e80 a2=6e a3=7fcd2d6523d40 items=0 ppid=1 pid=1820 auid=4294967295 uid=996 gid=994 euid=996 suid=996 fsuid=996 egid=994 sgid=994 fsgid=994 tty=(none) ses=4294967295 comm="mysqld" exe="/usr/sbin/mysqld" subj=system_u:system_r:mysqld_t:s0 key=(null)
type=AVC msg=audit(1566106187.784:152): avc:  denied  { create } for  pid=1820 comm="mysqld" name="mysql.sock" scontext=system_u:system_r:mysqld_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=sock_file

Aby rozwiązać problem odmowy SELinuksa, spróbuj przywrócić domyślny kontekst katalogu (twoja dystrybucja powinna ustawić poprawny kontekst mysqld_db_tpodczas instalacji MySQL lub MariaDB):

restorecon -R -v -f /var/lib/mysql

Jeśli dostosowałeś konteksty w swoim systemie, rozwiązanie problemu wykracza poza zakres tego postu.

Na podstawie tego, co piszesz, sugeruję sprawdzenie, czy system plików jest zamontowany tylko do odczytu.

130408 ​​11:31:22 mysqld_safe Uruchamianie demona mysqld z bazami danych z / var / lib / mysql / usr / libexec / mysqld: Wtyczka tabeli jest tylko do odczytu

Wypróbowałem wszystkie pozostałe odpowiedzi, aby rozwiązać problem. Wygląda na to, że kiedy ustawię selinux na permissive: setenforce 0Mogę uruchomić serwer.

Następnie zmieniłem katalog skarpet /var/lib/mysqlnadając uprawnienia selinux do katalogu:

semanage fcontext -a -t mysqld_db_t "/var/lib/mysql(/.*)?"
restorecon -R -v -f /var/lib/mysql

Po zakończeniu włączam selinux przy użyciu setenforce 1uruchomionej usługi mysql i wszystko poszło dobrze.

Mam nadzieję, że to pomaga innym.