Maxscale log rotation stymies logrotate

Rotating maxscale logs via SIGUSR1, or flush logs, picks a new "maxscaleN.log" filename to begin writing to. This scheme violates assumptions that logrotate uses to count the number of logs retained, when using maxscale's documented logrotate configuration example.

Logrotate assumes that the filename will not change upon rotation - that the writing process will either reopen its logging filehandle at the original name, or will be restarted, effectively accomplishing the same thing.

Maxscale is using some internal logfile generation number, creating a new filename. When logrotate encounters this new name (with no apparent previous rotations), it determines that this is a new file with no rotations. This leads to old rotations never being removed.

Best practice would be to change the USR1 handling to simply reopen the logging file handle. This allows the external actor (logrotate) to move the file to a new name, and signal the maxscale service to reopen the original file location when appropriate.