After upgrading to 15.04, I have had lots of fun getting to know systemd. I think I have everything working except I am unable to stop mysql.service; the systemctl command just hangs and mysql just keeps on running. Has anyone else experienced this or might know what's going on?
I had the same problem (upgrade to 15.04, using official files and config).
I had to make the following changes to be able to stop the
mysql daemon manually with
sytemctl and automatically on system reboot/shutdown:
/etc/mysql/debian.cnfreadable for the
sudo chgrp mysql /etc/mysql/debian.cnf; sudo chmod 640 /etc/mysql/debian.cnf
Provide a slightly modified
sudo cp /lib/systemd/system/mysql.service /etc/systemd/system/ sudo chmod 755 /etc/systemd/system/mysql.service
Provide an explicit stop command by opening the copied file in an editor:
sudo nano /etc/systemd/system/mysql.service
and adding the following line under the
ExecStop=/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf shutdown
In Nano, use Ctrl+O to save (Linux way!), Ctrl+X to exit.
Make the new service file known to system:
sudo systemctl daemon-reload
Your problem is thread_pool_size. If it's much higher than the number of cores/threads, you'll not be able to shutdown properly unless by using mysqladmin shutdown command.
Eg.: You have 2 cores CPU with 4 threads. If you set it 1-4 - it will work fine. If you set it to 16, as advised in many 'high performance' blogs, it'll get pooched.
I had a similar issue with mysql / mariadb failing to stop when instructed by systemd, either on shutdown or called manually with
sudo service mysql stop.
In my case I am dual-booting Ubuntu / Windows in UEFI mode, and these OS interpret different hardware time, so both OSs sync against Internet time servers when they start up.
MySQL (and Mariadb) was failing to stop if the hardware time changed while it are running.
You need to defer starting MySQL until after the timesync. Ideally this would be done by inserting a temporal dependency on mysql with
After: time-sync but that didn't work for me.
The solution that worked for me (You can replace mysql with mariadb for the same effect):
Disable mysql with
sudo systemctl disabled mysql.service
Create a script (ensure it's executable) that will start mysql after some delay
#!/bin/sh sleep 30s /etc/init.d/mysql start
Create a systemd service to run your new script
[Unit] Description=Delay start of MySQL / MariaDB [Service] Type=oneshot ExecStart=/usr/bin/delay_mysql [Install] WantedBy=multi-user.target
Register your new service with
sudo systemctl enable delay_mysql.service
This will cause your script to run at multi-user levels, which on Ubuntu are 3,4,5.
in my case it was password mismatch for maintenance user
debian-sys-maint between one in
/etc/mysql/debian.cnf and one in MySQL database.
This user is used for MySQL shutdown and other functions. After MySQL update it might happened that there is a pass mismatch between file and database.
This could also happen if you move your database from one MySQL to another. If you will import all databases and users from other MySQL on different machine you need to re-sync your maintenance user (
debian-sys-maint ) password.
You need to do: check your current password in ubuntu/debian file:
sudo cat /etc/mysql/debian.cnf # Automatically generated for Debian scripts. DO NOT TOUCH! [client] host = localhost user = debian-sys-maint password = n4aSHUP04s1J32X5 socket = /var/run/mysqld/mysqld.sock [mysql_upgrade] user = debian-sys-maint password = n4aSHUP04s1J32X5 socket = /var/run/mysqld/mysqld.sock basedir = /usr
You can see your password that system will use here:
password = n4aSHUP04s1J32X5
Next step is to update MySQL to same password: Log into MySQL:
~$ mysql -u root -p
Type your password to access MySQL
mysql> GRANT ALL PRIVILEGES ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY 'n4aSHUP04s1J32X5';**
After that no more issues with shutdown, no 10 min wait, no issues with installing apps that use this maintenance account like phpmyadmin.
UPDATE: So unfortunately this did not solve the issue. It made it kind of random - sometimes I can stop the service without issue another time it will freeze on service stop.