I'd say "rewrite slow/general/error logs to use the logger service".
Obvious issues:

• error log often goes to stderr, this cannot use the logger
• logs can be sent to a table. It would be great if the logger would support it, but realistically we'll probably only use the logger for files.

A thought:

• with more and more logger instances (more than one, in fact) we may want to have consistent names for command-line options/server variables for all logs, instead of doing them ad hoc per log in plugins or in the server. Something like: every log automatically creates --log-<logname>-* set of options/variables. This means logs have to be declared statically, not created dynamically.

I have setup log rotation using the new unix_socket plugin to authenticate without password. This solves getting logrotate to work. I have had it running for a month without issues on a Redhat server

Yes, that's a very good idea!
We'll be doing the same for our debian packages too (debian used to create a special maintenance mariadb user with a password stored somewhere in /etc, unix_socket is a much better solution).

Note the SQL_ERROR_LOG already does its own size based rotation.

This means logs have to be declared statically, not created dynamically.

Er yuck!

unix_socket is a much better solution

Having the patch in MDEV-7781 merged would make packaging significantly easier.

The other issue with logrotation on RHEL machines is the selinux permission on the datadir can't also be labeled to make logrotate to hande

Another way is to at least normalize the internally logging so its compatible with a systemd journal API http://www.freedesktop.org/wiki/Software/systemd/catalog/

Yes, of course. When we'll have an internal logging API used consistently for all logs, it would be easy to extend it to log to systemd journal or to syslog or anywhere else.

• I assume FLUSH LOGS will "rotate" all logs?
• Some logs (binlogs) have an existing numbering system; will the others? Perhaps they should not, else scripts that look for "hostname-slow.log" will fail. There could still be numbering on the archived logs.
• binlogs have both expire_logs_days and a cap on binlog size before automatically rotating. Consider both for the other logs. (Yeah, that expands the scope of this task, and you may not want to do it in the first pass.)

This was added in https://github.com/MariaDB/server/commit/ac647f5a3

documentation updated: https://mariadb.com/kb/en/mariadb/flush/