CentOS 5.5: MySQL ne démarre pas
Résolu/Fermé
A voir également:
- CentOS 5.5: MySQL ne démarre pas
- Photostudio 5.5 gratuit français - Télécharger - Retouche d'image
- Télécharger wampserver 5.5 gratuit - Télécharger - Divers Web & Internet
- Bryce 5.5 - Télécharger - 3D
- Cheat engine 5.5 - Télécharger - Outils Internet
- Emergency mode centos 7 - Forum Redhat
4 réponses
mamiemando
Messages postés
33076
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
17 avril 2024
7 748
Modifié par mamiemando le 19/11/2010 à 01:09
Modifié par mamiemando le 19/11/2010 à 01:09
Vu le message d'erreur c'est simplement que la connexion à la base est mauvaise. Vérifie que :
1) que le démon mysqld est lancé en tant qu'utilisateur mysql correctement.
... devrait ressembler à ceci :
2) qu'il écoute sur le port que tu crois (voir /etc/my.cnf) et que la bind-adress est correcte (ceci dit vu que c'est en local a priori c'est bon) dans la section mysqld :
... devrais contenir :
3) que le port est ouvert (a priori c'est 3306 qui est utilisé) :
... devrait renvoyer :
4) que le login mysql et le mot de passe que tu utilises dans ton code php sont corrects. En particulier, essaye de les tester avec la commande :
5) qu'un pare-feu ne bloque pas ce port (même si encore une fois, le fait qu'apache et mysql soient sur la même machine rendent cette hypothèse peu crédible). En root :
En cas de blocage reporte-moi le résultat de ces commandes.
Bonne chance
1) que le démon mysqld est lancé en tant qu'utilisateur mysql correctement.
ps aux | grep mysqld
... devrait ressembler à ceci :
mysql 1679 0.0 0.8 137160 18080 ? Sl 00:46 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306
2) qu'il écoute sur le port que tu crois (voir /etc/my.cnf) et que la bind-adress est correcte (ceci dit vu que c'est en local a priori c'est bon) dans la section mysqld :
cat /etc/mysql/my.cnf
... devrais contenir :
[mysqld] # # * Basic Settings # user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp language = /usr/share/mysql/english skip-external-locking # # Instead of skip-networking the default is now to listen only on # localhost which is more compatible and is not less secure. bind-address = 127.0.0.1
3) que le port est ouvert (a priori c'est 3306 qui est utilisé) :
netstat -ntlp | grep 3306
... devrait renvoyer :
(Tous les processus ne peuvent être identifiés, les infos sur les processus non possédés ne seront pas affichées, vous devez être root pour les voir toutes.) tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN -
4) que le login mysql et le mot de passe que tu utilises dans ton code php sont corrects. En particulier, essaye de les tester avec la commande :
mysql -u le_login_utilise_par_php -p -h 127.0.0.1
5) qu'un pare-feu ne bloque pas ce port (même si encore une fois, le fait qu'apache et mysql soient sur la même machine rendent cette hypothèse peu crédible). En root :
iptables --list
En cas de blocage reporte-moi le résultat de ces commandes.
Bonne chance
Salut mamiemando,
Merci pour ton aide, mais je crois que je suis vraiment dans la m**** la, parce que j'ai tapper ces commandes, mais j'ai pas - mais alors, vraiment pas - l'impression que les résultats soient positifs. Vois par toi-même:
1°)
j'obtiens ceci:
Donc mysqld est lancé en tant que root, pas en tant que mysql, mais vu que root a tout les droits, ça devrait pas passer tout de même ? Enfin bon, c'est juste une question à part.
Ensuite, le 2°)
...ca ne passe pas, car mon fichier my.cnf est direct dans le dossier etc/, je n'ai pas de dossier mysql, donc ma commande est devenu...
...
et c'est là que je commence vraiment à avoir peur:
Il manque un paquet d'infos apparemment :S
Penses-tu que je devrais les rajouter "à la main" ?
3°)
...ben, naturellement, vu l'état de mon my.cnf, cette commande ne me renvoie rien. Par contre la commande...
...me renvoie ceci (au cas où ça peut être utile):
Puis, le 4°) alors, je précise que c'est un serveur "vierge", il n'y a rien dessus, j'ai juste fait la mise à jour pour le moment. Il n'y a aucune base de donnée, aucun site hébergé pour l'instant, donc aucun script. Par contre, il y a plesk qui, je pense (et apparemment, c'est effectivement le cas), essaie de s'y connecter. Je suppose que vu qu'il n'y a rien, c'est normal, mais je pense pas que ce soit normal que mysql ne se lance pas du tout. Pour preuve, la commande suivante:
qui me donne:
Mais, au cas où, j'ai tout de même tester cette commande en tant que root,
et j'obtient ceci:
Et enfin, le 5°)
j'obtiens...
...mais, je ne sais pas du tout à quoi ça correspond.
Encore une fois, vraiment merci pour ton aide. Si tu pouvais me permettre de sortir de cette impasse, je t'en serai grandement reconnaissant...ainsi qu'à toutes personne susceptible de me donner un coup de main ;)
Merci pour ton aide, mais je crois que je suis vraiment dans la m**** la, parce que j'ai tapper ces commandes, mais j'ai pas - mais alors, vraiment pas - l'impression que les résultats soient positifs. Vois par toi-même:
1°)
ps aux | grep mysqld
j'obtiens ceci:
root 3785 0.0 0.0 61152 764 pts/0 R+ 07:33 0:00 grep mysqld
Donc mysqld est lancé en tant que root, pas en tant que mysql, mais vu que root a tout les droits, ça devrait pas passer tout de même ? Enfin bon, c'est juste une question à part.
Ensuite, le 2°)
cat /etc/mysql/my.cnf
...ca ne passe pas, car mon fichier my.cnf est direct dans le dossier etc/, je n'ai pas de dossier mysql, donc ma commande est devenu...
...
cat /etc/my.cnf
et c'est là que je commence vraiment à avoir peur:
[mysqld] set-variable=local-infile=0 datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql # Default to using old password format for compatibility with mysql 3.x # clients (those using the mysqlclient10 compatibility package). old_passwords=1 [mysqld_safe] log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid
Il manque un paquet d'infos apparemment :S
Penses-tu que je devrais les rajouter "à la main" ?
3°)
netstat -ntlp | grep 3306
...ben, naturellement, vu l'état de mon my.cnf, cette commande ne me renvoie rien. Par contre la commande...
netstat -ntlp
...me renvoie ceci (au cas où ça peut être utile):
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN 1590/couriertcpd tcp 0 0 0.0.0.0:995 0.0.0.0:* LISTEN 1607/couriertcpd tcp 0 0 0.0.0.0:106 0.0.0.0:* LISTEN 1567/xinetd tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 1598/couriertcpd tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN 1580/couriertcpd tcp 0 0 0.0.0.0:8880 0.0.0.0:* LISTEN 1514/sw-cp-serverd tcp 0 0 127.0.0.1:10001 0.0.0.0:* LISTEN 1514/sw-cp-serverd tcp 0 0 82.165.146.145:53 0.0.0.0:* LISTEN 1680/named tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 1680/named tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 1567/xinetd tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 22307/postmaster tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 1680/named tcp 0 0 0.0.0.0:8443 0.0.0.0:* LISTEN 1514/sw-cp-serverd tcp 0 0 :::80 :::* LISTEN 939/httpd tcp 0 0 :::22 :::* LISTEN 22394/sshd tcp 0 0 :::443 :::* LISTEN 939/httpd
Puis, le 4°) alors, je précise que c'est un serveur "vierge", il n'y a rien dessus, j'ai juste fait la mise à jour pour le moment. Il n'y a aucune base de donnée, aucun site hébergé pour l'instant, donc aucun script. Par contre, il y a plesk qui, je pense (et apparemment, c'est effectivement le cas), essaie de s'y connecter. Je suppose que vu qu'il n'y a rien, c'est normal, mais je pense pas que ce soit normal que mysql ne se lance pas du tout. Pour preuve, la commande suivante:
service mysqld start
qui me donne:
MySQL Daemon failed to start. Starting mysqld: [FAILED]
Mais, au cas où, j'ai tout de même tester cette commande en tant que root,
mysql -u root -p -h 127.0.0.1
et j'obtient ceci:
ERROR 2003 (HY000): Can't connect to MySQL server on '127.0.0.1' (111)
Et enfin, le 5°)
iptables --list
j'obtiens...
Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
...mais, je ne sais pas du tout à quoi ça correspond.
Encore une fois, vraiment merci pour ton aide. Si tu pouvais me permettre de sortir de cette impasse, je t'en serai grandement reconnaissant...ainsi qu'à toutes personne susceptible de me donner un coup de main ;)
mamiemando
Messages postés
33076
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
17 avril 2024
7 748
Modifié par mamiemando le 21/11/2010 à 14:26
Modifié par mamiemando le 21/11/2010 à 14:26
1) Non, ce que tu récupères c'est le processus associé à la commande grep que tu as tapé derrière ps. En d'autres termes mysqld n'est pas lancé du tout.
2) Ça l'air un peu différent ce que j'ai mais ce n'est pas forcément ultra choquant.
3) Comme mysqld n'est pas lancé, il est normal que tu ne voies rien.
4) Ça par contre ce n'est pas normal. C'est le message que tu dois copier coller dans google pour amorcer tes recherches. Cela vient peut être du fait que ton /etc/mysql/my.cnf est mal rempli. En corrigeant ce fichier, tu devrais pouvoir à terme lancer ton service mysql, qui lancera le démon mysqld, qui lui-même ouvrira une socket sur le port 3306.
5) Tout va bien ce n'est donc pas un problème de pare-feu (qui aurait pu être la cause de ton problème, ou une cause supplémentaire).
Voici mon fichier /etc/mysql/my.cnf, c'est celui qui est utilisé de base sous Debian :
... et voici /etc/mysql/conf.d/mysqld_safe_syslog.cnf :
Bonne chance
2) Ça l'air un peu différent ce que j'ai mais ce n'est pas forcément ultra choquant.
3) Comme mysqld n'est pas lancé, il est normal que tu ne voies rien.
4) Ça par contre ce n'est pas normal. C'est le message que tu dois copier coller dans google pour amorcer tes recherches. Cela vient peut être du fait que ton /etc/mysql/my.cnf est mal rempli. En corrigeant ce fichier, tu devrais pouvoir à terme lancer ton service mysql, qui lancera le démon mysqld, qui lui-même ouvrira une socket sur le port 3306.
5) Tout va bien ce n'est donc pas un problème de pare-feu (qui aurait pu être la cause de ton problème, ou une cause supplémentaire).
Voici mon fichier /etc/mysql/my.cnf, c'est celui qui est utilisé de base sous Debian :
# # The MySQL database server configuration file. # # You can copy this to one of: # - "/etc/mysql/my.cnf" to set global options, # - "~/.my.cnf" to set user-specific options. # # One can use all long options that the program supports. # Run program with --help to get a list of available options and with # --print-defaults to see which it would actually understand and use. # # For explanations see # https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html # This will be passed to all mysql clients # It has been reported that passwords should be enclosed with ticks/quotes # escpecially if they contain "#" chars... # Remember to edit /etc/mysql/debian.cnf when changing the socket location. [client] port = 3306 socket = /var/run/mysqld/mysqld.sock # Here is entries for some specific programs # The following values assume you have at least 32M ram # This was formally known as [safe_mysqld]. Both versions are currently parsed. [mysqld_safe] socket = /var/run/mysqld/mysqld.sock nice = 0 [mysqld] # # * Basic Settings # user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp language = /usr/share/mysql/english skip-external-locking # # Instead of skip-networking the default is now to listen only on # localhost which is more compatible and is not less secure. bind-address = 127.0.0.1 # # * Fine Tuning # key_buffer = 16M max_allowed_packet = 16M thread_stack = 192K thread_cache_size = 8 # This replaces the startup script and checks MyISAM tables if needed # the first time they are touched myisam-recover = BACKUP #max_connections = 100 #table_cache = 64 #thread_concurrency = 10 # # * Query Cache Configuration # query_cache_limit = 1M query_cache_size = 16M # # * Logging and Replication # # Both location gets rotated by the cronjob. # Be aware that this log type is a performance killer. # As of 5.1 you can enable the log at runtime! #general_log_file = /var/log/mysql/mysql.log #general_log = 1 # # Error logging goes to syslog due to /etc/mysql/conf.d/mysqld_safe_syslog.cnf. # # 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 # # The following can be used as easy to replay backup logs or for replication. # note: if you are setting up a replication slave, see README.Debian about # other settings you may need to change. #server-id = 1 #log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 10 max_binlog_size = 100M #binlog_do_db = include_database_name #binlog_ignore_db = include_database_name # # * InnoDB # # InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/. # Read the manual for more InnoDB related options. There are many! # # * Security Features # # Read the manual, too, if you want chroot! # chroot = /var/lib/mysql/ # # For generating SSL certificates I recommend the OpenSSL GUI "tinyca". # # ssl-ca=/etc/mysql/cacert.pem # ssl-cert=/etc/mysql/server-cert.pem # ssl-key=/etc/mysql/server-key.pem [mysqldump] quick quote-names max_allowed_packet = 16M [mysql] #no-auto-rehash # faster start of mysql but no tab completition [isamchk] key_buffer = 16M # # * 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/
... et voici /etc/mysql/conf.d/mysqld_safe_syslog.cnf :
[mysqld_safe] syslog
Bonne chance
