bchin what does cat /proc/cpuinfo show on the machine?
Also, could you check if /usr/share/maxscale contains any files? If it does, I think it installed correctly but the invalid instruction is causing it to not start.
Created symlink /etc/systemd/system/multi-user.target.wants/maxscale.service → /usr/lib/systemd/system/maxscale.service.
|
|
|
Verifying : libtool-ltdl-2.4.6-45.el9.x86_64 1/4
|
Verifying : unixODBC-2.3.9-4.el9.x86_64 2/4
|
Verifying : libatomic-11.3.1-2.1.el9.x86_64 3/4
|
Verifying : maxscale-23.02.1-1.rhel.9.x86_64 4/4
|
|
|
Installed:
|
libatomic-11.3.1-2.1.el9.x86_64 libtool-ltdl-2.4.6-45.el9.x86_64 maxscale-23.02.1-1.rhel.9.x86_64 unixODBC-2.3.9-4.el9.x86_64
|
|
|
Complete!
|
[root@karma033 ~]# ls /usr/share/maxscale/
|
COPYRIGHT LICENSE-THIRDPARTY.TXT LICENSE2302.TXT ReleaseNotes.txt cdc_schema.go create_roles.sql maxscale maxscale.conf maxscale_logrotate prerm
|
Changelog.txt LICENSE.TXT README.md UpgradingToMaxScale12.txt create_grants gui maxscale.cnf.template maxscale.service postinst
|
[root@karma033 ~]# cat /proc/cpuinfo
|
processor : 0
|
vendor_id : GenuineIntel
|
cpu family : 6
|
model : 44
|
model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
|
stepping : 2
|
microcode : 0x1f
|
cpu MHz : 2401.000
|
cache size : 12288 KB
|
physical id : 0
|
siblings : 8
|
core id : 0
|
cpu cores : 4
|
apicid : 0
|
initial apicid : 0
|
fpu : yes
|
fpu_exception : yes
|
cpuid level : 11
|
wp : yes
|
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes lahf_lm epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid dtherm ida arat flush_l1d
|
vmx flags : vnmi preemption_timer invvpid ept_x_only ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple
|
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
|
bogomips : 4799.70
|
clflush size : 64
|
cache_alignment : 64
|
address sizes : 40 bits physical, 48 bits virtual
|
power management:
|
And 15 more core info.
Looks like the CPU doesn't support AVX or AVX2. Is this a virtualized environment of some sorts?
This is a bare metal machine. just an old cpu.
Can you start MaxScale under GDB and see if you can catch where the problem is occurring? Something like this should work:
sudo gdb -batch -ex 'r -d -lstdout -U maxscale' /usr/bin/maxscale
|
[root@karma033 ~]# gdb -batch -ex 'r -d -lstdout -U maxscale' /usr/bin/maxscale
|
...
|
Downloading separate debug info for /lib64/libresolv.so.2...
|
Downloading separate debug info for /root/.cache/debuginfod_client/dd26798426928fb454335411ecfeb883030b1f6c/debuginfo...
|
Downloading separate debug info for /lib64/libsasl2.so.3...
|
Downloading separate debug info for /root/.cache/debuginfod_client/78a77f792072693b0a303f6d8924eeee033fb498/debuginfo...
|
|
|
Program received signal SIGILL, Illegal instruction.
|
0x00007ffff7b9fa5c in _GLOBAL__sub_I_simd_canonical.cc () at /usr/include/c++/11/ext/new_allocator.h:79
|
79 new_allocator() _GLIBCXX_USE_NOEXCEPT { }
|
[root@karma033 ~]#
|
Oh yeah, it doesn't print the stacktrace if it's not requested 
Could you try again by running GDB manually:
sudo gdb /usr/bin/maxscale
|
Then once GDB has started, start MaxScale with:
r -d -lstdout -U maxscale
|
Once it stops and hits that problem, run the bt command to get the full stacktrace.
this doesn't look useful, but hopefully it helps
[root@karma033 ~]# gdb /usr/bin/maxscale
|
GNU gdb (GDB) Red Hat Enterprise Linux 10.2-10.el9
|
Copyright (C) 2021 Free Software Foundation, Inc.
|
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
|
This is free software: you are free to change and redistribute it.
|
There is NO WARRANTY, to the extent permitted by law.
|
Type "show copying" and "show warranty" for details.
|
This GDB was configured as "x86_64-redhat-linux-gnu".
|
Type "show configuration" for configuration details.
|
For bug reporting instructions, please see:
|
<https://www.gnu.org/software/gdb/bugs/>.
|
Find the GDB manual and other documentation resources online at:
|
<http://www.gnu.org/software/gdb/documentation/>.
|
|
|
For help, type "help".
|
Type "apropos word" to search for commands related to "word"...
|
Reading symbols from /usr/bin/maxscale...
|
(gdb) r -d -lstdout -U maxscale
|
Starting program: /usr/bin/maxscale -d -lstdout -U maxscale
|
[Thread debugging using libthread_db enabled]
|
Using host libthread_db library "/lib64/libthread_db.so.1".
|
|
|
Program received signal SIGILL, Illegal instruction.
|
0x00007ffff7b9fa5c in _GLOBAL__sub_I_simd_canonical.cc () at /usr/include/c++/11/ext/new_allocator.h:79
|
79 new_allocator() _GLIBCXX_USE_NOEXCEPT { }
|
Missing separate debuginfos, use: dnf debuginfo-install maxscale-23.02.1-1.rhel.9.x86_64
|
(gdb) bt
|
#0 0x00007ffff7b9fa5c in _GLOBAL__sub_I_simd_canonical.cc () at /usr/include/c++/11/ext/new_allocator.h:79
|
#1 0x00007ffff7fd11ae in call_init (env=0x7fffffffe3e8, argv=0x7fffffffe3b8, argc=5, l=<optimized out>) at dl-init.c:70
|
#2 call_init (l=<optimized out>, argc=5, argv=0x7fffffffe3b8, env=0x7fffffffe3e8) at dl-init.c:26
|
#3 0x00007ffff7fd129c in _dl_init (main_map=0x7ffff7ffe220, argc=5, argv=0x7fffffffe3b8, env=0x7fffffffe3e8) at dl-init.c:117
|
#4 0x00007ffff7fe7b0a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
|
#5 0x0000000000000005 in ?? ()
|
#6 0x00007fffffffe663 in ?? ()
|
#7 0x00007fffffffe675 in ?? ()
|
#8 0x00007fffffffe678 in ?? ()
|
#9 0x00007fffffffe681 in ?? ()
|
#10 0x00007fffffffe684 in ?? ()
|
#11 0x0000000000000000 in ?? ()
|
(gdb)
|
I think that actually turned out to be very useful output. It shows that this is probably happening when the linker loads the core MaxScale library and somehow AVX instructions end up spilling over where they shouldn't be called.