MySQL Bugs: #86728: log_sink_json service doesn't work with rpm default installation

Bug #86728	log_sink_json service doesn't work with rpm default installation
Submitted:	16 Jun 2017 10:37	Modified:	5 Oct 2017 15:54
Reporter:	Ramana Yeruva	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Installing	Severity:	S3 (Non-critical)
Version:	8.0.2	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
In 8.0 there are few logging services added to have custom logging format in wl#9323.once this service is enabled then any logging displayed in json format on console if no log-error specified during server startup and mysqld.log.00.json will be created if log-error specified and log info written there.Same works fine with tar.gz packages but not with rpms.

How to repeat:
install rpms rom 8.0 repository where log-error=/var/log/mysqld.log generated by default in /etc/my.cnf with rpms
start service.
run below commands from mysql client
install component "file://component_log_sink_json";
set @@global.log_error_services='log_sink_json';
install any command which write info to log file,ex:install plugin mysqlx soname 'mysqlx.so' 
observe there is no info written anywhere.

same works if server started with log-error=/tmp/mysqld.log for which /tmp/mysqld.log.00.json generated

would be helpful if there is message in normal log if the json file can't be opened by rpm mysqld

Posted by developer:
 
Notes.
On RPM install, we create an empty (default/traditional) error log,
and chown it to mysql:mysql. That's how we can later write to the
old-style log despite it being in a directory that's neither ours,
nor sticky.
We don't do the same thing for the JSON plug-in. Therefore, it can't write,
the poor thing. Conversely, user successfully test with /tmp, as that's
most likely sticky.

It's tempting to update the install script to at least do the same
for the *first* JSON log (if the DBA wants more than one log, leave
that to manual setup; add a Docs note to that effect).

Terje however cautions against setting up a bunch of unused files
though, and notes that this in fact also requires restorecon on
selinux, etc. It would also be necessary to be multi-instance aware.
The JSON writer currently derives its log name from the traditional
log's; the install script would have to follow the same conventions.
(e.g. if you have --log-error=/tmp/foo.log and you configure a JSON
writer, you get /tmp/foo.log.00.json)

Any sane person would probably persist the error log stack set-up;

  SET PERSIST @@global.log_error_services="log_sink_json";

or such like. Which would mean that some variant of

  egrep '"log_error_services": "[^"]*log_sink_json[^"]*" }' mysqld-auto.conf

could detect the use of the JSON log-writer, but only *after*
the server's been started (and failed to write to the JSON log) once.

As a general action-item, we should possibly log an error on failure in
log_builtins_imp::open_errstream(), but since we may up in a situation
without ANY working log-writers, it may be more relevant to fail
SET @@global.log_error_services; if any of the requested services
fail to set up, i.e. we need to document a convention for signaling this.

Posted by developer:
 
Fixed in 9.0.0.

if a configured error log service existed but could not be
initialized, log information was lost. Now if a log service is
configured at startup but cannot be initialized, diagnostics about
the problem are sent to the default log service (or if that fails,
directly to the error stream), and the server exits. If a log service
is configured at runtime but cannot be initialized, diagnostics are
sent to the client.