Which version was this encountered with? It is possibly related to log flushing errors found in 1.3.0 which were fixed for 1.4.0.

1.3.0

Please try to reproduce with the 1.4.0 beta version of MaxScale. With it, the logs are fully flushed to disk when MaxScale exits.

just tested with 1.4.1:

nothing in the log!

[vagrant@maxscale ~]$ maxscale --version-full

MariaDB Corporation MaxScale 1.4.1 Mon Apr 4 09:55:33 2016
------------------------------------------------------
MaxScale 1.4.1 - 5219e94af74ba5b49bdc480e7861f32ca3c95744
[vagrant@maxscale ~]$ sudo service maxscale start
Starting maxscale (via systemctl): Job for maxscale.service failed. See 'systemctl status maxscale.service' and 'journalctl -xn' for details.
[FAILED]
[vagrant@maxscale ~]$ cat /var/log/maxscale/maxscale1.log
[vagrant@maxscale ~]$ sudo service maxscale status
Checking MaxScale status: maxscale.service - MariaDB MaxScale Database Proxy
Loaded: loaded (/usr/lib/systemd/system/maxscale.service; disabled)
Active: failed (Result: exit-code) since Mon 2016-04-04 09:55:48 EDT; 24s ago
Process: 4534 ExecStart=/usr/bin/maxscale --user=maxscale (code=exited, status=1/FAILURE)
Process: 4532 ExecStartPre=/usr/bin/install -d /var/run/maxscale -o maxscale -g maxscale (code=exited, status=0/SUCCESS)

Apr 04 09:55:48 maxscale systemd[1]: Starting MariaDB MaxScale Database Proxy...
Apr 04 09:55:48 maxscale maxscale[4534]: MariaDB Corporation MaxScale 1.4.1 Mon Apr 4 09:55:48 2016
Apr 04 09:55:48 maxscale maxscale[4534]: ------------------------------------------------------
Apr 04 09:55:48 maxscale systemd[1]: maxscale.service: control process exited, code=exited status=1
Apr 04 09:55:48 maxscale systemd[1]: Failed to start MariaDB MaxScale Database Proxy.
Apr 04 09:55:48 maxscale systemd[1]: Unit maxscale.service [FAILED]failed state.
[vagrant@maxscale ~]$ /usr/bin/maxscale --user=maxscale

MariaDB Corporation MaxScale 1.4.1 Mon Apr 4 09:56:29 2016
------------------------------------------------------
Error: Failed to change group to '997': 1 Operation not permitted
[vagrant@maxscale ~]$ sudo /usr/bin/maxscale --user=maxscale

MariaDB Corporation MaxScale 1.4.1 Mon Apr 4 09:56:32 2016
------------------------------------------------------
[vagrant@maxscale ~]$ ps ax | grep maxscale
4564 pts/0 D+ 0:00 grep --color=auto maxscale
[vagrant@maxscale ~]$ cat /var/log/maxscale/maxscale1.log
[vagrant@maxscale ~]$

Error messages that were logged before the log manager was initialized were ignored.

still does not work:

[vagrant@maxscale ~]$ sudo chmod 400 /etc/maxscale.cnf
[vagrant@maxscale ~]$ maxscale

MariaDB Corporation MaxScale 1.4.2 Wed Apr 20 03:57:10 2016
------------------------------------------------------
[vagrant@maxscale ~]$
[vagrant@maxscale ~]$ sudo chmod 777 /etc/maxscale.cnf
[vagrant@maxscale ~]$ maxscale

MariaDB Corporation MaxScale 1.4.2 Wed Apr 20 03:57:25 2016
------------------------------------------------------
*

• Error : Can't access /var/log/maxscale/maxscale1.log due to Permission denied.
• Opening file /var/log/maxscale/maxscale2.log failed due 13, Permission denied.
  Error : opening logfile /var/log/maxscale/maxscale2.log failed.
  Error : opening log file /var/log/maxscale/maxscale2.log failed. Exiting MaxScale
  *
• Error : Initializing log manager failed.
  *
  [vagrant@maxscale ~]$

Log is empty.

The daemon mode no longer affects the output of the error messages to stdout. This will allow easier detection of problems in the configuration.

The case where no log messages were logged was most likely caused by the lack of write permissions to the logging directory and it should be fixed with the code in commit 3046b4a46e70cd19db95397fc4754f2981594d0c with additional error logging printed to stdout.

fixed in 1.4.3, merged to develop.
Test 'mxs621_unreadable_cnf' is added. Closing.