Details
-
New Feature
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Won't Do
Description
Can we keep MariaDB (relatively) aligned to the MySQL's behavior on SIGHUP & SIGUSR1?
I've tested w/ MariaDB 10.11 and
- for SIGHUP - after MySQL 8.0.20 the server does not write anymore the status report in the error log file, MariaDB still does - not taking sides on this one - in my opinion it is debatable if that output can be considered an "error.log", more like a candidate for "general.log", but I wouldn't suppress it completely either;
- for SIGUSR1 - this exists with MySQL 8.0.19 and newer, MariaDB ignores this.
The latter SIGUSR1 is useful for log file rotation as it covers a subset of the operations done in SIGHUP.
Also the same mechanism is used by others (example: Nginx rotates logs at SIGUSR1).
Attachments
Activity
I am wondering if there are really use cases where a system admin (someone using kill) needs to control MariaDB internals. As danblack said, there exist ways via mariadb command line tools, and these at least need a server authentication.
Thanks eradical,
While in many cases we would still like to be a bit more MySQL compatible, there's a limit on engineering time and if there isn't a good user benefit for the feature we probably won't do it.
Status information, its not really a query log for the general log either. Its hard to say when/how/if this is still used. I think I'd rather direction be decided by people who do use it or find the verboseness in error.log intrusive.
On SIGUSR1 for log rotate, we've currently a variety of FLUSH commands available via mariadb-admin - https://github.com/MariaDB/server/blob/11.5/support-files/mariadb.logrotate.sh#L55-L56 (
MDEV-22659). These depend on a server authentication, and we've provided root@localhost identified via unix_socket since 10.4.Is there a strong use case beyond just normalization?