Impossible de démarrer mysql avec:
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
Un autre mysql n'est pas en cours d'exécution:
[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
Les autorisations sur "/ tmp" et "/ var / lib / mysql" sont 777 /
Aucune suggestion?
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 et plugin.frm existent dans / var / lib / mysql / mysql /.
Rien ne fonctionne sur le port 3306.
mysql.sock n'existe pas. J'ai essayé de le créer moi-même, mais après le redémarrage, il a été supprimé.
montage (tous 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)
Ce problème est apparu aujourd'hui lorsque j'ai essayé de cloner mon site sur un sous-domaine.
mysql_upgrade
comme suggéré?Réponses:
1) Assurez-vous d'abord de supprimer le fichier socket existant à l'aide de la commande rm.
2) Tuez tous les processus MySQL existants via la commande suivante.
3) Très important: assurez-vous que l'autorisation pour le répertoire de base de données MySQL sous
/var/lib/
dossier doit être mysql: root4) Avec les informations ci-dessus, vous devriez pouvoir démarrer MySQL avec succès et le fichier socket doit être créé avec succès sous le répertoire de la base de données.
la source
Grâce à la réponse de @ Abhishek combinée à la sortie mysqld (impossible d'utiliser /var/run/mysqld/mysqld.sock), j'ai réussi à résoudre ce problème avec une seule commande:
Ensuite, il démarre correctement:
la source
Votre problème peut être dû à toute condition qui empêche le démon MySQL d'écrire un fichier socket dans le chemin
/var/lib/mysql
. Les autres réponses, comme un système de fichiers en lecture seule ou une propriété de répertoire incorrecte, traitent de diverses raisons pour lesquelles MySQL peut ne pas être en mesure d'écrire dans le socket.Une autre raison possible est que
/var/lib/mysql
le contexte SELinux est incorrect. Vous pouvez diagnostiquer cette condition en vérifiant les récents refus SELinux AVC après avoir tenté de démarrer le démon MySQL:ausearch -m avc --start recent
Si SELinux refuse l'accès pour créer le fichier socket, vous verrez un message d'erreur comme celui-ci:
Pour résoudre un refus SELinux, essayez de restaurer le contexte par défaut du répertoire (votre distribution doit définir le contexte correct
mysqld_db_t
lorsque vous avez installé MySQL ou MariaDB):restorecon -R -v -f /var/lib/mysql
Si vous avez personnalisé les contextes de votre système, la résolution du problème dépasse le cadre de cet article.
la source
Sur la base de ce que vous écrivez, je vous suggère de vérifier si votre système de fichiers est monté en lecture seule.
la source
J'ai essayé toutes les autres réponses pour résoudre le problème. Il semble que lorsque j'ai défini selinux sur permissive:
setenforce 0
je pouvais démarrer le serveur.J'ai ensuite modifié le répertoire sock en
/var/lib/mysql
accordant des autorisations selinux au répertoire:Une fois cela fait, j'active selinux en utilisant
setenforce 1
le service mysql et tout allait bien.J'espère que cela aide les autres.
la source