I followed this tutorial to install MySQL 8.0 on my centos 6 Virtual server.
Tutorial
However when I get to the step where Im supposed to start the service (service mysqld start)
I get the following error:
Initializing MySQL database: [ OK ]
/usr/bin/mysqld_safe: line 199: 1632 Killed env MYSQLD_PARENT_ PID=1450 nohup /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin -dir=/usr/lib/mysql/plugin --user=mysql --log-error=/var/log/mysqld.log --pid-fi le=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock < /dev/null > / dev/null 2>&1
MySQL Daemon failed to start.
Starting mysqld: [FAILED]
I tried serveral times and always get an error, does anyone know how to fix this?
I ran into this problem, and after inspecting journalctl -xe, I saw that it was due to an out-of-memory error. I solved this by upgrading from a 512MB RAM to a 1GB RAM for my virtual machine
Related
I have recently bought a new laptop running Ubuntu 16.04.1 LTS (64 bit). I have installed dozens of applications, but one is giving me a major headache and any help would be gratefully received.
I start from a clean slate with regard to mysql:
sudo apt remove --purge mysql-server mysql-client mysql-common
sudo apt autoremove
sudo rm -rf /var/lib/mysql*
sudo apt install mysql-server
I install my database from backup and everything works fine.
I power-off/power-on the laptop and mysql isn't working. Firstly the daemon is not running:
ps -A | grep sql
2056 ? 00:00:00 mysql-systemd-s
but something I don't recognise called mysql-systemd-s is running.
It is now impossible to use mysql:
mysql -u root -p
Enter password:
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial
communication packet', system error: 104
The service seems to be unstartable:
service mysql start
Job for mysql.service failed because the control process exited with
error code. See "systemctl status mysql.service" and "journalctl -xe"
for details.
but neither of these is useful. The /var/log/mysql/error.log has a little more information:
......
2017-01-13T21:01:04.926244Z 0 [Warning] Failed to set up SSL because
of the following SSL library error: SSL context is not usable without
certificate and private key
2017-01-13T21:01:04.926272Z 0 [Note] Server hostname (bind-address):
'127.0.0.1'; port: 3306
2017-01-13T21:01:04.926288Z 0 [Note] - '127.0.0.1' resolves to
'127.0.0.1';
2017-01-13T21:01:04.926327Z 0 [Note] Server socket created on IP:
'127.0.0.1'.
2017-01-13T21:01:04.927774Z 0 [ERROR] Fatal error: mysql.user table is damaged. Please run mysql_upgrade.
2017-01-13T21:01:04.927897Z 0 [ERROR] Aborting
However, the recommendation to run mysql_upgrade is useless because one can't run mysql_upgrade unless the mysql server is running! And the mysql server isn't running because of this error.
So, I remove and re-install everything and run mysql_upgrade. This seems to complete without error. But, again when I power cycle the machine, I'm back without mysql working.
I have also tried starting the mysqld with the --skip-grant-tables options, but this still does not allow connexion.
At the moment, every time I reboot my computer I have to remove all traces of mysql, re-install mysql and then reload my database from a backup. This is a real pain.
Does anyone have any ideas about what's happening?
Problem appears to be resolved. The clue was that mysqld seemed to survive a power-off/power-on if I didn't restore my own database backup. It didn't if I did restore that backup.
Generally, I never look at my database backups; rather I just do a mysqldump and keep the resulting file in case of a rainy day.
Given the clues above, I took a look at the file that had been produced by mysqldump and reduced it to its minimum size so that it just contained the database that I wanted to restore. That appears to have done the trick.
I have kept the bad file and have been playing with diffs to find what was nasty in it, but haven't yet found it.
I'm trying to use MySQL on Arch Linux. it is already installed but this error comes up when I try to connect:
connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/run/mysqld/mysqld.sock' (2 "No such file or directory")'
I've looked for /etc/my.cfg but the file does not exist.
Something must have gone wrong during the installation.
How can I "purge" MariaDB and reinstall it?
If you're using archlinux it is a vital idea to understand the package manager (pacman). For the question about /etc/my.cfg you can run
pacman -Ql mariadb
there you will see that the file is actually called:
/etc/mysql/my.cnf
Arch linux will not configure the package for you, that is part of the arch philosophy. It will provide example configurations, and even provide you with a systemd unit file
usr/lib/systemd/system/mysqld.service
but it is your responsibility to ensure that the configuration is correct and actually start the daemon.
systemctl enable mysqld # add the unit file to the boot sequence
systemctl start mysqld # runs ExecStart= in the unit file
systemctl stop mysqld # kills the daemon
systemctl disable mysqld # remove unit from boot sequence
reinstall
Since the word reinstall is in the title of the question and someone might find this question thanks to that: To reinstall mariadb you simply do
pacman -S mariadb
pacman will reinstall a package that is already installed, there is no need to remove the package (for completeness, package removal happens with pacman -R)
as of 7-28-17 I had to do this on a new install. Newbie here might save someone some time. It was a real pain.
OK HERE IS THE DEAL!!!!!
INSTALL APACHE _ NO PROB
INSTALL MYSQL _PROBLEM
pacman -S mysql then before starting service
MUST UNCOMMENT INNODB IN:
nano /etc/mysql/my.cnf
then must initialize datadirectory before starting service:
mysql_install_db --user=mysql --basedir=/usr --datadir=/var/lib/mysql
You need to initialize the MariaDB data directory prior to starting
the service. This can be done with mysql_install_db command, e.g.:
mysql_install_db --user=mysql --basedir=/usr --datadir=/var/lib/mysql
Optional dependencies for mariadb
galera: for MariaDB cluster with Galera WSREP
perl-dbd-mysql: for mysqlhotcopy, mysql_convert_table_format and
mysql_setpermission
CNF file is /etc/mysql/my.cnf in Arch Linux.
One simple way I can reproduce your issue is when MariaDB is shut down. Sorry if it sounds dumb but as you did not mention it: is MariaDB started? sudo systemctl start mysqld.service
You should have a look at MariaDB logs to get some clue: journalctl _SYSTEMD_UNIT=mysqld.service (maybe paste some part if you still don't get what is going on).
This happens the first time you install MySQL and MariaDB. As grochmal pointed out, you have to set up configurations before first use. But, the user teckk sent these three links in the archlinux newbie corner:
https://wiki.archlinux.org/index.php/MariaDB
https://wiki.archlinux.org/index.php/MariaDB#Reset_the_root_password
https://bbs.archlinux.org/viewtopic.php?id=51981
In short, you have to run the command below before starting the service:
sudo mariadb-install-db --user=mysql --basedir=/usr --datadir=/var/lib/mysql
Optionally (recommended) you should improve the initial security by calling:
sudo mysql_secure_installation
Now you can start the service:
sudo systemctl start mariadb
Optionally, you could install and use a graphical front-end tool.
Carry on with setting up the configurations as described in the archwiki post on MariaDB Configuration.
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 have couchbase version 2.2.0 installed on 6.7 and it worked fine.
But when i changed the centos version from 6.7 to 6.6, couchbase is not starting at all.
Is couchbase having problem with centos 6.6? Noticed some issues at https://issues.couchbase.com/browse/MB-12536 and https://issues.couchbase.com/browse/MB-12849
But could not get the solution with centos 6.6.
If anybody faced the issue, would be helpful if you could let me know how make couchbase 2.2.0 with centos 6.6
[root#localhost ~]# service couchbase-server start
Starting couchbase-server/usr/bin/dirname: extra operand `2>&1.pid'
Try `/usr/bin/dirname --help' for more information.
[ OK ]
[root#localhost ~]# service couchbase-server restart
Stopping couchbase-serverNOTE: shutdown failed
{badrpc,nodedown}
Starting couchbase-server/usr/bin/dirname: extra operand `2>&1.pid'
Try `/usr/bin/dirname --help' for more information. [ OK ]
Thank you.
I believe the following will solve your problem. Edit your couchbase-server file in /etc/init.d as follows. Change:
daemon --user couchbase "$DAEMON -- -noinput -detached > /opt/couchbase/var/lib/couchbase/logs/start.log 2>&1"
to:
daemon --user couchbase "$DAEMON" -- -noinput -detached > /opt/couchbase/var/lib/couchbase/logs/start.log 2>&1
I.e. don't surround the whole command with quotes just the DAEMON env var. Also change:
daemon "$DAEMON: -k"
to:
daemon "$DAEMON" -k
so it stops right too. That should do it. Let me know if not.
I have recently installed 5.5.28-29.2 Percona Server (GPL), Release 29.2 in a Ubuntu 12.04 OS Desktop. I have tried to stop the server using different methods:
- sudo /etc/init.d/mysql stop
- sudo kill -9 pid
- mysqladmin -u root -p shutdown
All this methods stop the process, however it starts up automatically after it dies. I have checked syslog (/var/log/syslog/) and always shows me the next trace:
Jan 4 17:50:44 kernel: [ 1915.494219] init: mysql main process (17311) killed by KILL signal
Jan 4 17:50:44 kernel: [ 1915.494245] init: mysql main process ended, respawning
Jan 4 17:50:44 kernel: [ 1915.500025] type=1400 audit(1357318244.557:48): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=18458 comm="apparmor_parser"
Jan 4 17:50:46 /etc/mysql/debian-start[18501]: Upgrading MySQL tables if necessary.
Jan 4 17:50:46 /etc/mysql/debian-start[18504]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Jan 4 17:50:46 /etc/mysql/debian-start[18504]: Looking for 'mysql' as: /usr/bin/mysql
Jan 4 17:50:46 /etc/mysql/debian-start[18504]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
Jan 4 17:50:46 /etc/mysql/debian-start[18504]: This installation of MySQL is already upgraded to 5.5.28, use --force if you still need to run mysql_upgrade
Jan 4 17:50:46 /etc/mysql/debian-start[18515]: Checking for insecure root accounts.
Jan 4 17:50:46 /etc/mysql/debian-start[18520]: Triggering myisam-recover for all MyISAM tables
Do you know the reason why the process restarts automatically ?
Thank you in advance!!
I was having this exact same problem. Running the kill command would kill the process, but in my case it would keep popping up again under a different process ID.
The only way I could figure out how to stop it for good was this:
sudo stop mysql
Source: http://www.itfromscratch.com/how-to-stop-the-percona-mysql-server/
Using sudo service mysql stop worked for me.
Want to kill all mysql instances? Try as root:
pkill mysqld;
I'm using Homebrew on Mac OS. brew services stop mysql did not work for me, but sudo brew services stop mysql did.
I'm going to guess here, but mysqld might be started via the mysql_safe init script, which will restart the server.
For those looking at this years after the fact, I had a similar issue and just solved it.
Seems there was a second init script called orig_mysql.conf that existed in the /etc/init directory along with the mysql.conf file. This caused upstart to start two instances and apparently it got confused when one was ended. As such a continuous respawning took place.
My solution:
Stop mysql via upstart if possible: service mysql stop
REMOVE one of the conf files (I removed /etc/init/orig_mysql.conf). Then restart init using: telinit u
Kill off any remaining mysqld processes manually.
Once you confirm you have no mysqld processes running and that they are not respawning any longer, restart mysql with service mysql start.
Hope this helps someone. It took me two years to solve this.
This might not apply to this particular problem but here it goes anyways. I checked the error log ("/var/log/mysql/error.log") and saw that "explicit_defaults_for_timestamp=TRUE" was causing an error ("Unknown variable"). So I removed it from my.cnf ("/etc/mysql/my.cnf"), and ran "sudo start mysql" and it was back up and running. I hope this helps as well!