WL#7793: Add native support for syslog on unixoid platforms
mysqld did not have native support for traditional unix-style syslog; it instead used a shell-script wrapper that would pipe the daemon's output to the syslog. This implied certain limitations: - it was impossible to see the syslog status at runtime - it was impossible to change the syslog status at runtime - the shell script could interfere with log rotation - the setup would often result in log lines containing two timestamps Clients and mysql/sun/orcl employees alike have therefore suggested to add native support of syslog on unixoid systems. cf. BUG#55370 mysqld general log output to syslog et al.
Functional requirements FR1 Logging to system facilities The server SHALL support output of diagnostic information to well-known system facilities: FR1.1 UNIX syslog On unixoid/POSIX systems, output to syslog SHALL be supported. FR1.2 Windows NT EventLog On Windows systems, output to NT EventLog SHALL be supported. FR2 Diagnostic information "Diagnostic information" in the context of this WL is all information already sent to stderr (and possibly piped to syslog by a wrapper), usually with a timestamp, a severity tag (error/warning/notice), and possibly other information. "Diagnostic information" for the purpose of this WL does not include information sent to auxiliary logs such as the slow query log or the general log, but MAY be extended to include such logs at a later date. FR2.1 Redundant information The implementation SHOULD take care not to duplicate information, for instance it SHOULD NOT include a timestamp in a log line sent to the system facilities when it would be reasonable to assume that the system facilities will add their own timestamp. FR2.2 Severity levels Where system facilities support this, the implementation SHOULD attempt to use severity levels that mirror those used in current Diagnostic Information and those sent to the client. Where the system facilities do not support an exact mapping or the use of such a mapping seems otherwise inadvisable, the implementation MAY opt to approximate such a mapping instead. FR3 Controls The implementation SHALL give the user access to / control over these features at start-up and at run-time. FR3.1 Start-up Parameters SHOULD be settable at start-up. FR3.2 Run-time FR3.2.1 Read-access Parameters SHALL be readable at run-time. FR3.2.2 Write-access Paramaters SHOULD be modifiable at run-time where supported by the underlying system facilities. Non-functional requirements NFR1 The implementation SHOULD attempt clean up and unify the rudimentary interfaces to system facilities present in my_syslog.c and log.cc, respectively.
USER VISIBLE CHANGES Add native syslog support for unixoid OSs. #1 mysqld sysvars / options The following can be set a start-up as well as viewed and set at runtime via system variables (requiring the SUPER privilege). --log_syslog[=0|1] on/off switch, defaults to off --log_syslog_include_pid[=0|1] Include mysqld's process ID on each syslog line? Defaults to on. --log_syslog-facility=local5 choose the syslog "facility". Well-known facilities may be selected by name, all others by numbers. Defaults to "daemon". --log_syslog-tag=
If empty and by default, an ident of "mysqld" is used. If e.g. tag "abcd" is supplied, "mysqld-abcd" will be used. (The hyphen will be used automatically, the user need not supply it.) This item is designed to closely emulate the syntax used by the current mysqld_safe script, so updating the script to use the server-side (rather than script-side) facilities is made easier, with an eye to keeping the script's parameters stable so its callers can remain unchanged in most cases, i.e. in the interest of making the transition as smooth as possible for the DBAs. Finally, moving this item into the server should simplify the planned rewrite of the wrapper scripts (mysqld_safe, mysqld_multi). #2 Severity mapping The severity mapping on unixoid platforms shall be as follows: ERROR_LEVEL -> syslog::error (3) WARNING_LEVEL -> syslog::warning (4) INFORMATION_LEVEL -> syslog::notice (5) This will make things uniform within the platform; i.e. something shown as "[Notice]" in the log file would show as "Notice" in syslog, and would further- more reflect the levels (error, warning, notice) sent to the client. For Windows NT Eventlog, the mapping would be as follows: ERROR_LEVEL -> EVENTLOG_ERROR_TYPE WARNING_LEVEL -> EVENTLOG_WARNING_TYPE INFORMATION_LEVEL -> EVENTLOG_INFORMATION_TYPE (I.e. the least severe message type would show as "information" rather than as "notice"; this is owed to the fact that a) that mapping is already used in GA servers, and b) no other suitable severity levels (especially one corresponding to "notice") exist in classic NT eventlog.) THE FUTURE / DEFERRED Future WL tasks may extend logging to syslog/eventlog by offering to also redirect the general and slow query logs. The present WL task was designed with this in mind and tries not to create hindrances for the possible later task. An additional log_output target "SYSLOG" could be added (while keeping the existing FILE and TABLE). If this target is active, general log and slow log items could be sent to syslog / EventLog in a way that makes them distinguishable from the error/warning/information item used by "error log" type items. One way of achieving this would be to use a separate EventSource / facility for the error log on one hand, and general/slow log on the other (or even to split them 3 way, error <-> slow <-> general). #3 --log_syslog-facility= would then become --log_syslog-facility= [, ] #4 --log_output=TABLE|FILE|NONE would become --log_output=TABLE|FILE|SYSLOG|NONE #5 my_openlog() / my_syslog() would have to be upgraded for multi-facility / multi-EventSource use. (Any further details on this to be placed in Low Level Design.) #6 The mapping for the POSIX syslog severity levels in #2 would allow for the remaining two levels to be mapped like so, slow log -> syslog::information (6) general log -> syslog::debug (7) This however does not readily translate to NT eventlog, so the "two facilities / two event-sources" design outlined above may prove more portable.
ENGINEERING CONSIDERATIONS #1 mysys/my_syslog.c already contains some code for syslog support (currently only used by the command line client). This code should be reworked to support the features configurable according to #1. #2 mysys/my_syslog.cc and sql/log.cc has some duplication of effort with regard to the Windows EventLog. Eliminate the duplicates from log.cc, and merge the remaining useful code into my_syslog.cc so that other binaries may have a chance to benefit from it. #3 As a special case, sql/conn_handler/socket_connection.cc when compiled with HAVE_LIBWRAP, will log auth failures to syslog. This feature currently uses the libC calls directly, and should be modified so it uses the corresponding my_*() calls, and does not interfere with other syslogging in mysqld.
Copyright (c) 2000, 2022, Oracle Corporation and/or its affiliates. All rights reserved.