# Systemctl start hangs for Xtradb 8.0 cluster on Ubuntu 22.04 LTS

**URL:** <https://forums.percona.com/t/systemctl-start-hangs-for-xtradb-8-0-cluster-on-ubuntu-22-04-lts/30942>\
**Category:** Percona XtraDB Cluster 8.x\
**Created:** [June 10, 2024, 12:42pm UTC](https://forums.percona.com/t/systemctl-start-hangs-for-xtradb-8-0-cluster-on-ubuntu-22-04-lts/30942 "2024-06-10T12:42:50Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![bsabalaskey](https://avatars.discourse-cdn.com/v4/letter/b/c77e96/32.png) [@bsabalaskey](https://forums.percona.com/u/bsabalaskey)\
**Post date:** [June 10, 2024, 12:42pm UTC](https://forums.percona.com/t/systemctl-start-hangs-for-xtradb-8-0-cluster-on-ubuntu-22-04-lts/30942/1 "2024-06-10T12:42:50Z")

</div>

I am trying XtraDB cluster on a 3 node setup with MySQL 8.0 and intended for WordPress CMS apps. I installed from the normal Percona getting started on Ubuntu using apt install method on Ubuntu 22.04 LTS. When I install the software and try to run systemctl start mysql@bootstrap.service (on the first node) or systemctl start mysql on the other nodes, the system service file times out after 2 minutes or hangs. In other terminal windows I check the DB process and logs and the DB and nodes run properly, as I can do normal operations like create users and query tables and such, but the systemd service file times out on the first node and hangs on the other nodes.

So it works, that is the systemctl exits normally after the start up, if I change the service file from type=notify to type=simple. (Yes, I did systemctl daemon-reload).

Is there some service script problem on Ubuntu 22.04 LTS? Is my service file hack safe to use in general, or are there other possible side effects for not using the type=notify setting?

---

<div class="post-metadata">

**Author:** ![Evgeniy\_Patlan](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/evgeniy_patlan/32/41_2.png) [@Evgeniy\_Patlan](https://forums.percona.com/u/Evgeniy_Patlan)\
**Post date:** [June 11, 2024, 4:09am UTC](https://forums.percona.com/t/systemctl-start-hangs-for-xtradb-8-0-cluster-on-ubuntu-22-04-lts/30942/2 "2024-06-11T04:09:19Z")

</div>

Hey @bsabalaskey  
Do you have any logs from the hang system?

---

<div class="post-metadata">

**Author:** ![bsabalaskey](https://avatars.discourse-cdn.com/v4/letter/b/c77e96/32.png) [@bsabalaskey](https://forums.percona.com/u/bsabalaskey)\
**Post date:** [June 11, 2024, 11:58am UTC](https://forums.percona.com/t/systemctl-start-hangs-for-xtradb-8-0-cluster-on-ubuntu-22-04-lts/30942/3 "2024-06-11T11:58:13Z")

</div>

What specific log(s) are you looking for? Just to reiterate, when I say hang, it is the systemctl service file that hangs at the end, but the mysql process runs and works normally, until on the 1st node the 2 minute timeout is hit, and then systemd kills the process. The other nodes just hangs indefinitely. The mysql logs show that mysql operates properly while it is running.

---

<div class="post-metadata">

**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\
**Post date:** [June 12, 2024, 9:48pm UTC](https://forums.percona.com/t/systemctl-start-hangs-for-xtradb-8-0-cluster-on-ubuntu-22-04-lts/30942/4 "2024-06-12T21:48:10Z")

</div>

@bsabalaskey, `systemctl status mysql` should be helpful after you experience a failed start. Even `journalctl -u mysql` should have something.

---

<div class="post-metadata">

**Author:** ![bsabalaskey](https://avatars.discourse-cdn.com/v4/letter/b/c77e96/32.png) [@bsabalaskey](https://forums.percona.com/u/bsabalaskey)\
**Post date:** [June 13, 2024, 8:19pm UTC](https://forums.percona.com/t/systemctl-start-hangs-for-xtradb-8-0-cluster-on-ubuntu-22-04-lts/30942/5 "2024-06-13T20:19:14Z")

</div>

The mysql process starts and runs fine. The systemd process =\> systemctl start mysql \<= hangs and never exits. Repeat; the problem is not mysql but systemd. Here is a bit of mysql logs since you insist.

2024-06-13T20:03:56.282247Z 12 [Note] [MY-000000] [WSREP] Server status change initialized → joined  
2024-06-13T20:03:56.282384Z 2 [Note] [MY-000000] [Galera] Draining apply monitors after IST up to 3491  
2024-06-13T20:03:56.289551Z 2 [Note] [MY-000000] [Galera] IST received: a1e4ae57-245b-11ef-8331-d2c44d035d6c:3491  
2024-06-13T20:03:56.289642Z 2 [Note] [MY-000000] [Galera] Recording CC from sst: 3491  
2024-06-13T20:03:56.289666Z 2 [Note] [MY-000000] [Galera] Lowest cert index boundary for CC from sst: 3478  
2024-06-13T20:03:56.289675Z 2 [Note] [MY-000000] [Galera] Min available from gcache for CC from sst: 3108  
2024-06-13T20:03:56.290065Z 0 [Note] [MY-000000] [Galera] 0.0 (db1): State transfer from 1.0 (db3) complete.  
2024-06-13T20:03:56.290093Z 0 [Note] [MY-000000] [Galera] SST leaving flow control  
2024-06-13T20:03:56.290109Z 0 [Note] [MY-000000] [Galera] Shifting JOINER → JOINED (TO: 3491)  
2024-06-13T20:03:56.290179Z 0 [Note] [MY-000000] [Galera] Processing event queue:… -nan% (0/0 events) complete.  
2024-06-13T20:03:56.290548Z 0 [Note] [MY-000000] [Galera] Member 0.0 (db1) synced with group.  
2024-06-13T20:03:56.290575Z 0 [Note] [MY-000000] [Galera] Processing event queue:…100.0% (1/1 events) complete.  
2024-06-13T20:03:56.290590Z 0 [Note] [MY-000000] [Galera] Shifting JOINED → SYNCED (TO: 3491)  
2024-06-13T20:03:56.290611Z 2 [Note] [MY-000000] [Galera] Server db1 synced with group  
2024-06-13T20:03:56.290630Z 2 [Note] [MY-000000] [WSREP] Server status change joined → synced  
2024-06-13T20:03:56.290646Z 2 [Note] [MY-000000] [WSREP] Synchronized with group, ready for connections  
2024-06-13T20:03:56.395134Z 0 [Note] [MY-000000] [Galera] 1.0 (db3): State transfer to 0.0 (db1) complete.  
2024-06-13T20:03:56.395585Z 0 [Note] [MY-000000] [Galera] Member 1.0 (db3) synced with group.  
2024-06-13T20:03:56.768378Z 0 [Note] [MY-000000] [Galera] (0eed56b8-9060, ‘tcp://0.0.0.0:4567’) turning message relay requesting off

---

<div class="post-metadata">

**Author:** ![bsabalaskey](https://avatars.discourse-cdn.com/v4/letter/b/c77e96/32.png) [@bsabalaskey](https://forums.percona.com/u/bsabalaskey)\
**Post date:** [July 8, 2024, 3:03pm UTC](https://forums.percona.com/t/systemctl-start-hangs-for-xtradb-8-0-cluster-on-ubuntu-22-04-lts/30942/6 "2024-07-08T15:03:06Z")

</div>

Bump.

Any hints at why the service file hangs by not recognizing that mysql actually starts?

---

<div class="post-metadata">

**Author:** ![Evgeniy\_Patlan](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/evgeniy_patlan/32/41_2.png) [@Evgeniy\_Patlan](https://forums.percona.com/u/Evgeniy_Patlan)\
**Post date:** [August 21, 2024, 6:32am UTC](https://forums.percona.com/t/systemctl-start-hangs-for-xtradb-8-0-cluster-on-ubuntu-22-04-lts/30942/7 "2024-08-21T06:32:55Z")

</div>

there is no useful info in the log you provided,  
Please follow @matthewb 's suggestion

---

<div class="post-metadata">

**Author:** ![nick-fox](https://avatars.discourse-cdn.com/v4/letter/n/5fc32e/32.png) [@nick-fox](https://forums.percona.com/u/nick-fox)\
**Post date:** [March 21, 2025, 3:08pm UTC](https://forums.percona.com/t/systemctl-start-hangs-for-xtradb-8-0-cluster-on-ubuntu-22-04-lts/30942/8 "2025-03-21T15:08:46Z")

</div>

I’ve also experienced this and found that issues with Apparmour.

`tail -f /var/log/syslog|grep systemd`

```auto
apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify"

```

Changing the systemd setting `Type=simple` looks to resolve the issue because the process will succeed as soon as mysqld starts rather than waiting to be notified.

* * *

The cause of the app armour issues is a miss configuration in `/etc/apparmor.d/usr.sbin.mysqld`

In `/etc/apparmor.d/usr.sbin.mysqld`. Change

```auto
/usr/sbin/mysqld flags=(complain) {

```

To

```auto
/usr/sbin/mysqld flags=(attach_disconnected complain) {

```

Test your AppArmour config `apparmor_parser -r /etc/apparmor.d/usr.sbin.mysqld` and start MySQL