[MXS-2258] GaleraMon crashes if it monitors a server that is not Galera-enabled Created: 2019-01-11  Updated: 2019-01-12  Resolved: 2019-01-12

Status: Closed
Project: MariaDB MaxScale
Component/s: galeramon
Affects Version/s: 2.3.2
Fix Version/s: 2.3.3

Type: Bug Priority: Major
Reporter: Geoff Montee (Inactive) Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None


 Description   

If MaxScale's GaleraMon attempts to monitor a server that is not Galera-enabled (i.e. maybe because the DBA forgot to set wsrep_on and/or wsrep_provider), then it will cause MaxScale to crash with the following stack crash:

2019-01-11 14:30:51   notice : Encrypted password file /var/lib/maxscale/.secrets can't be accessed (No such file or directory). Password encryption is not used.
2019-01-11 14:30:54   error  : [Galera-Monitor] Failed to connect to server 'C1N2' ([172.30.0.32]:3306) when checking monitor user credentials and permissions: Can't connect to MySQL server on '172.30.0.32' (110)
2019-01-11 14:30:57   error  : [Galera-Monitor] Failed to connect to server 'C1N3' ([172.30.0.46]:3306) when checking monitor user credentials and permissions: Can't connect to MySQL server on '172.30.0.46' (110)
2019-01-11 14:30:57   notice : Starting a total of 2 services...
2019-01-11 14:30:58   alert  : Fatal: MaxScale 2.3.2 received fatal signal 11. Attempting backtrace.
2019-01-11 14:30:58   alert  : Commit ID: 1126c687a4570f60ee26a163520198a3263ccbbd System name: Linux Release string: Red Hat Enterprise Linux Server release 7.2 (Maipo)
2019-01-11 14:30:58   alert  :   /usr/bin/maxscale(_ZN7maxbase15dump_stacktraceESt8functionIFvPKcS2_EE+0x2b) [0x40cbeb]: /home/vagrant/MaxScale/maxutils/maxbase/src/stacktrace.cc:130
2019-01-11 14:30:58   alert  :   /usr/bin/maxscale(_ZN7maxbase15dump_stacktraceEPFvPKcS1_E+0x4e) [0x40cf4e]: /usr/include/c++/4.8.2/functional:2029
2019-01-11 14:30:58   alert  :   /usr/bin/maxscale() [0x4095c9]: ??:0
2019-01-11 14:30:58   alert  :   /lib64/libpthread.so.0(+0xf5e0) [0x7f23c088e5e0]: sigaction.c:?
2019-01-11 14:30:58   alert  :   /lib64/libc.so.6(+0x13cfaf) [0x7f23be8b2faf]: :?
2019-01-11 14:30:58   alert  :   /usr/lib64/maxscale/libgaleramon.so(_ZN13GaleraMonitor20update_server_statusEP16monitored_server+0x364) [0x7f23b81f3174]: /usr/include/c++/4.8.2/bits/basic_string.h:1131 (discriminator 4)
2019-01-11 14:30:58   alert  :   /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN8maxscale21MonitorInstanceSimple4tickEv+0xba) [0x7f23c0d9fcda]: /home/vagrant/MaxScale/server/core/monitor.cc:2815
2019-01-11 14:30:58   alert  :   /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN8maxscale15MonitorInstance12run_one_tickEv+0x21) [0x7f23c0d9e5e1]: /home/vagrant/MaxScale/maxutils/maxbase/include/maxbase/atomic.hh:42
2019-01-11 14:30:58   alert  :   /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN8maxscale15MonitorInstance17call_run_one_tickEN7maxbase6Worker4Call8action_tE+0x56) [0x7f23c0d9e686]: /home/vagrant/MaxScale/server/core/monitor.cc:2946
2019-01-11 14:30:58   alert  :   /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN7maxbase6Worker4tickEv+0xe6) [0x7f23c0de4366]: /home/vagrant/MaxScale/maxutils/maxbase/include/maxbase/worker.hh:777
2019-01-11 14:30:58   alert  :   /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN7maxbase11WorkerTimer6handleEPNS_6WorkerEj+0x36) [0x7f23c0de2b06]: /home/vagrant/MaxScale/maxutils/maxbase/src/worker.cc:256
2019-01-11 14:30:58   alert  :   /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN7maxbase6Worker15poll_waiteventsEv+0x1b5) [0x7f23c0de3505]: /home/vagrant/MaxScale/maxutils/maxbase/src/worker.cc:844
2019-01-11 14:30:58   alert  :   /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN7maxbase6Worker3runEPNS_9SemaphoreE+0x51) [0x7f23c0de3701]: /home/vagrant/MaxScale/maxutils/maxbase/src/worker.cc:545
2019-01-11 14:30:58   alert  :   /lib64/libstdc++.so.6(+0xb5220) [0x7f23bf8c0220]: ??:0
2019-01-11 14:30:58   alert  :   /lib64/libpthread.so.0(+0x7e25) [0x7f23c0886e25]: pthread_create.c:?
2019-01-11 14:30:58   alert  :   /lib64/libc.so.6(clone+0x6d) [0x7f23be86e34d]: ??:?

Maybe this should fail more gracefully instead of crashing?



 Comments   
Comment by markus makela [ 2019-01-12 ]

Fixed in commit 8c437c6440caf6b556f3429f03802d5907620338.

Generated at Thu Feb 08 04:12:49 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.