2

I had installed and started Percona XtraDB Cluster 5.7 on 3 nodes. Everything went fine, until I had rebooted my first node. From then mysql.service couldn't be (re)started normally:

[root@percona1]# systemctl restart mysql.service
Failed to restart mysql.service: Unit not found.

I want to properly start mysql (percona server) on this node, as on my other nodes. This is what I'm getting on the first node:

[root@percona1]# systemctl status mysql.service
    ● mysql.service
       Loaded: not-found (Reason: Invalid argument)
       Active: active (running) since Tue 2019-08-13 16:24:31 CEST; 24h ago
     Main PID: 1931 (mysqld_safe)
       CGroup: /system.slice/mysql.service
               ├─1931 /bin/sh /usr/bin/mysqld_safe --basedir=/usr
               └─2515 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --user=mysql --wsrep-provider=/usr/lib64/galera3/libgalera_smm.so --log-error=/var/log/my...

    Aug 13 16:23:47 percona1 systemd[1]: Starting Percona XtraDB Cluster...
    Aug 13 16:23:48 percona1 mysqld_safe[1931]: 2019-08-13T14:23:48.456697Z mysqld_safe Logging to '/var/log/mysqld.log'.
    Aug 13 16:23:48 percona1 mysqld_safe[1931]: 2019-08-13T14:23:48.463619Z mysqld_safe Logging to '/var/log/mysqld.log'.
    Aug 13 16:23:48 percona1 mysqld_safe[1931]: 2019-08-13T14:23:48.524311Z mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
    Aug 13 16:23:48 percona1 mysqld_safe[1931]: 2019-08-13T14:23:48.553983Z mysqld_safe Skipping wsrep-recover for af1dd70d-b928-11e9-a530-aa3807a48b86:9 pair
    Aug 13 16:23:48 percona1 mysqld_safe[1931]: 2019-08-13T14:23:48.557526Z mysqld_safe Assigning af1dd70d-b928-11e9-a530-aa3807a48b86:9 to wsrep_start_position
    Aug 13 16:23:51 percona1 mysql-systemd[1932]: State transfer in progress, setting sleep higher
    Aug 13 16:24:31 percona1 mysql-systemd[1932]: SUCCESS!
    Aug 13 16:24:31 percona1 systemd[1]: Started Percona XtraDB Cluster.
    Aug 14 14:28:10 percona1 systemd[1]: Current command vanished from the unit file, execution of the command list won't be resumed.


[root@percona1]# journalctl -xe
    Aug 14 17:05:59 percona1 polkitd[572]: Registered Authentication Agent for unix-process:12131:9882093 (system bus name :1.106 [/usr/bin/pkttyagent --notify-fd 5 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
    Aug 14 17:06:00 percona1 polkitd[572]: Unregistered Authentication Agent for unix-process:12131:9882093 (system bus name :1.106, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)


[root@percona1]# systemd-analyze verify mysql.service
    Error: org.freedesktop.systemd1.NoSuchUnit: Unit not found.
    Failed to create mysql.service/start: No such file or directory

Note: percona3 has been bootstrapped and percona2 has been started normally (systemctl start mysql.service). The problem is only with percona1 and to me it looks like it is systemd related.

Sevak
  • 21
  • 1
  • 1
  • 5
  • Does it work when you run `/etc/init.d/mysql start` ? – Valentin Bajrami Aug 14 '19 at 16:43
  • centos 7 is a systemd based, there are no init.d scripts, only systemd services files. `[root@percona1]# systemctl list-unit-files | grep mysql mysql.service bad mysql@.service enabled mysqld.service bad pmm-mysql-metrics-42002.service enabled pmm-mysql-queries-0.service enabled` – Sevak Aug 15 '19 at 08:39
  • Sure and we run percona / galera clusters as well but occasionally there are issues with the systemd files. For certain services there are still `rc` scripts available so the transision from old sysV / Upstart to systemd goes somehow transparent. You might also check your `/var/lib/mysql` permissions. If SELinux is causing anything etc.. – Valentin Bajrami Aug 15 '19 at 09:09
  • /var/lib/mysql `drwxr-x--x. 6 mysql mysql 4096 Aug 15 10:45 mysql ` . in `/etc/selinux/config` is `SELINUX=permissive` and `SELINUXTYPE=targeted` – Sevak Aug 15 '19 at 09:25
  • I guess this issue has something to do with systemd, but don't know where to look for. `systemctl list-unit-files | grep mysql` gives `mysql.service bad`. – Sevak Aug 15 '19 at 09:35
  • Do the unit files that Percona was supposed to have installed actually exist? Did you run `systemctl daemon-reload`? – Michael Hampton Aug 15 '19 at 09:36
  • I ran `systemctl daemon-reload` but nothing changed. These are my unit files: `[root@percona1 mysql]# ls -l /etc/systemd/system/mysql* lrwxrwxrwx. 1 root root 38 Aug 12 14:25 /etc/systemd/system/mysql.service -> /usr/lib/systemd/system/mysql@.service lrwxrwxrwx. 1 root root 37 Aug 7 17:12 /etc/systemd/system/mysqld.service -> /usr/lib/systemd/system/mysql.service` `[root@percona1 mysql]# ls -l /usr/lib/systemd/system/mysql* -rw-r--r--. 1 root root 1024 Jun 20 07:47 /usr/lib/systemd/system/mysql.service -rw-r--r--. 1 root root 1987 Jun 20 07:47 /usr/lib/systemd/system/mysql@.service` – Sevak Aug 15 '19 at 09:52
  • Thing is, that mysql can be run by `systemctl start mysqld.service`, not by `systemctl start mysql.service` as on other nodes. And this is what is appended in the the systemd log: `Current command vanished from the unit file, execution of the command list won't be resumed.` – Sevak Aug 15 '19 at 09:59

1 Answers1

-1

There is probably a service (let's call it rogue.service) that has a "Requires" dependency on mysql.service and a dependency on another service (let's call it missing.service), where missing.service is not present on the machine.

qbert220
  • 174
  • 2