Downgraded to major as it is not one of our officially supported platforms. We are of course interested in getting MaxScale to run on that as well.
Please add
log_info=1
|
to your configuration file and restart MaxScale. Is anything logged when you attempt to connect with maxadmin?
log_debug=1
|
will cause even more to be logged.
Tried adding both the parameters as mentioned above still no logs related to maxadmin could be seen except for below which is logged when we start maxscale : Listening for connections at [localhost]:6603 with protocol MaxScale Admin
Have you tried using a Unix domain socket instead?
https://github.com/mariadb-corporation/MaxScale/blob/2.2/Documentation/Reference/MaxAdmin.md#configuring-mariadb-maxscale-for-maxadmin
Note that in that case you initially have to be root when using maxscale. Once you have been able to connect you can enable other users as explained here:
https://github.com/mariadb-corporation/MaxScale/blob/2.2/Documentation/Reference/MaxAdmin.md#enabling-a-linux-account
And you could also try with
[MaxAdmin Listener]
|
type=listener
|
service=MaxAdmin Service
|
protocol=maxscaled
|
address=0.0.0.0
|
port=6603
|
Yes - with Unix domain socket also it did not work - same issue as before.
We could not get MaxScale command interface(which is seen once maxadmin starts), so could not try enabling other user for maxadmin.
Changing address=0.0.0.0 - same issue is seen.
Any update on this? It will be helpful for us to proceed if we get some pointers on this.
Please provide further help on this, as its blocking our Maxscale use case verification.
Any pointers on this?
Hi team,
Please let us know what more we can try from our side to get maxadmin work.
Hi to all,
I have faced the same issue. Aftersome debugging I was able to figure out the cause. This issue is actually related to parsing the command line arguments and the problem is also applicable to the maxbinlogcheck binary. Both maxadmin and maxbinlogcheck use getopt_long to parse the command line argumets, but unfortunately the return value is stored in the variable 'c' defined as char, which causes an infinite while loop when parsing the options. According to GNU documentation the return type of getopt_long should be int. I havent investigated the problem further but during assignment of int into a char the actual return value is lost and hence the infinite loop. So, when you change the type of the variable 'c' to int everything works fine. related files are "./clients/maxadmin.c" and "./server/modules/routing/binlogrouter/maxbinlogcheck.c" You have to build everything fresh. Hope this helps.
Yes Thank you A. Gokhan YAVUZ for sharing the information 
. We have debugged and resolved this issue.
aligokhan Thanks for detecting this, we will include this fix.
Now correct return type is used.