Woke up this morning to the server’s ApisCP backend and MariaDB being down. ApisCP says it is a failed migration.
Steps to Reproduce
Unsure. This was automated in the backend. MariaDB 10.5.25 shows a database error and is unable to start. upcp says there is a failed migration, but is unable to recover.
Expected Behavior
cd /usr/local/apnscp && ./artisan migrate --force should be able to recover, but it fails claiming there is no such file or directory in the MySQL. Mariadb.service is unable to start.
Actual Behavior
Mariadb is unable to start and ApisCP is not recovering.
Give that a go. I had a workaround for their capabilities in 2020 that looks to have been fixed in MariaDB/server@76a27155b4cd. Any 10.4+ release is susceptible to the change with 10.5 being the first new release featuring this change.
As per the suggestions on the Discord support, I started MariaDB in safe mode.
I have not installed the older minor version of MariaDB as of this moment. This is still on 10.5.25.
I entered the commands and saw edge pull today’s update via upcp.
TASK [mysql/install : systemd] *************************************************
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Unable to start service mariadb: Warning: The unit file, source configuration file or drop-ins of mariadb.service changed on disk. Run 'systemctl daemon-reload' to reload units.\nJob for mariadb.service failed because the control process exited with error code.\nSee \"systemctl status mariadb.service\" and \"journalctl -xe\" for details.\n"}
Don’t put in safe mode or anything of that nature. Run upcp, which includes a migration that runs upcp -sb mysql/install that in turn removes the AmbientCapabilities and CapabilityBoundingSet directives from /etc/systemd/system/mariadb.service.d/override.conf…
