Details
Major
Description
Upgraded to MariaDB 10.0.6 today (via aptitude upgrade) and configured the newly available TokuDB engine as my default engine, after changing the configuration file I restarted the server with service mysql restart. The server restarted normally but the following message was printed to the console after the restart finished (and blocked the prompt).
root@s1:~# ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111 "Connection refused")
The funny part is that I simply hit Ctrl + C and type mysql -u root -p and connecting to server works as expected. Same goes for my PHP application that uses mysqlnd to access the database. No problems with anything, just that awkward error message on the prompt.
I attached my complete my.cnf file.
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Already forgot about this report. Nope, the problem was gone with one of he new releases of MariaDB, I guess we can simply close it.
Set 'fixed version' to 10.0.10 simply because it was the first GA, I suppose if it weren't fixed by then, there would have been more complaints.
Somehow this report got missed, sorry about that, but we still need to handle it.
The message most certainly comes from /etc/mysql/debian-start. Right after starting the server, the startup script calls /etc/mysql/debian-start which performs some operations in the background. If it fails, it would behave exactly as described – print the message, come up to the foreground taking the prompt, and go away on Ctrl+C. So, it must be it.
Now, since the startup script first checks that the server is responsive by pinging it through mysqladmin, and mysqladmin uses the same configuration file as the debian script, the connectivity issue should not happen, unless the startup script, the debian script or the debian config were somehow tampered with. I did install 10.0.6 with the provided config, but I"m not getting the problem.
However, 10.0.6 was very immature and crashed easily. I suppose it's possible that the debian script would start running, executed the first call (it has three total), crashed the server which would begin restarting, meanwhile the script would proceed to another call which would fail to connect because the server is not available at the moment. Of course, it's just a wild guess, we would need the error log and maybe the general log to find out what was going on.
The important question is whether it is still happening. If it does, it should be fairly easy to investigate, if it does not, then there is no reason to bother, there have been tons of changes in 10.0 since 10.0.6.
Once again, sorry that the report was ignored, it was an operational mistake.