The Ultimate Guide to High Availability with MariaDB
This is a read-only copy of the MariaDB Knowledgebase generated on 2024-12-24. For the latest, interactive version please visit https://mariadb.com/kb/.

Maxscale not starting on Ubuntu 22.04

Hi ,

I use Maxscale without any issues on multiple installations on several Ubuntu versions: U18.04, U20.04. I ran into a strange issues on U22.04. After the default install (so with default config) Maxscale already simply refuses to start. From syslog:

May 9 11:35:16 rolf-test systemd[1]: Starting MariaDB MaxScale Database Proxy... May 9 11:35:16 rolf-test kernel: [ 7609.013814] traps: maxscale[7474] trap invalid opcode ip:7fd516cd8c4f sp:7fff8c5bff30 error:0 in libmaxscale-common.so.1.0.0[7fd516ca3000+27e000] May 9 11:35:16 rolf-test systemd[1]: maxscale.service: Control process exited, code=dumped, status=4/ILL May 9 11:35:16 rolf-test systemd[1]: maxscale.service: Failed with result 'core-dump'. May 9 11:35:16 rolf-test systemd[1]: Failed to start MariaDB MaxScale Database Proxy. May 9 11:35:16 rolf-test systemd[1]: maxscale.service: Scheduled restart job, restart counter is at 636. May 9 11:35:16 rolf-test systemd[1]: Stopped MariaDB MaxScale Database Proxy.

I tried multiple Mascxale versions, all produced the same error. I suspect something is wrong in the Ubuntu 22.04 VMware virtual machine but have no idea. No other issues. I even tried mutlipe U22.04 VM's on multiple different ESX-hosts.

Anybody any idea ?

Regards, Rolf

Answer Answered by Rolf Benneker in this comment.

I am not sure anymore if I got the same error with the code from git.

But the problem for me is solved by changing the EVC setting in VMware. Somebody forgot to update this setting :( Now the VM's have AVX CPU support and Maxscale works as a charme !

Tanks for pointing me in the right direction !

Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.