Comment 5 for bug 1600164

I also have this problem with Ubuntu 16.04.2 LTS:

| $ lsb_release --all
| No LSB modules are available.
| Distributor ID: Ubuntu
| Description: Ubuntu 16.04.2 LTS
| Release: 16.04
| Codename: xenial
|
| $ dmidecode -s system-product-name
| VirtualBox

After a reboot the activation time of MySQL is one hour ahead.

1. If I wait one hour after reboot, I can shutdown MySQL instantly:

| $ systemctl status mysql.service
| ...
| Active: active (running) since Fri 2017-02-10 18:20:08 CET; 59min left
| ...
|
| $ date
| Fri Feb 10 17:20:54 CET 2017
|
| $ sleep 60m
|
| $ date
| Fri Feb 10 18:21:02 CET 2017
|
| $ systemctl status mysql.service
| ...
| Active: active (running) since Fri 2017-02-10 18:20:08 CET; 57s ago
| ...
|
| $ time systemctl stop mysql.service
|
| real 0m4.928s
| user 0m0.028s
| sys 0m0.008s

2. If I try it earlier, the shutdown fails after 10 minutes and MySQL gets killed by systemd with SIGKILL.

3. If I increase the systemd timeout of MySQL to two hours, then the shutdown successfully ends after one hour. The attached error-20170210.log contains this case and also the time jump:

| 2017-02-10T15:22:26.962776Z 0 [Note] /usr/sbin/mysqld: ready for connections.
| ...
| 2017-02-10T14:23:52.465978Z 0 [Note] Giving 0 client threads a chance to die gracefully

4. As suggested, I tried to start MySQL after the ntp.service, but it didn't helped:

| $ apt-get install ntp
|
| $ grep ^After /lib/systemd/system/mysql.service
| After=ntp.service
|
| $ systemctl show mysql.service | grep ^After
| After=ntp.service basic.target system.slice systemd-journald.socket sysinit.target

5. I also tried to start MySQL after the systemd-timesyncd.service, but it also didn't helped:

| $ cat /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
| ...
| ConditionFileIsExecutable=!/usr/sbin/ntpd
| ...
|
| $ dpkg --purge ntp
|
| $ grep ^After /lib/systemd/system/mysql.service
| After=systemd-timesyncd.service
|
| $ systemctl show mysql.service | grep ^After
| After=systemd-timesyncd.service system.slice basic.target systemd-journald.socket sysinit.target

6. Is there anything else I can try or do?

7. Maybe the importance of this issue should be raised, because killing MySQL during its shutdown with SIGKILL feels a bit risky.