faust This was pretty well debugged downstream in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922018, to fix this I guess you only need to change one string/variable? Could you fix this upstream?
otto as this is "debian specific" I have no idea on how to cleanly fix this upstream.
Here is the code:
https://github.com/MariaDB/server/blob/10.6/scripts/mysql_install_db.sh#L564
We could add something like:
if debian; then |
log_file_place="/var/log/mysql" |
else
|
log_file_place=$ldata
|
fi |
Then what is the bast practice for Debian OS detection.
Maybe you or anel or danblack have a better idea?
What about using `show variables like 'log_error';`?
Why is it using `/var/lib` for logs on non-Debian platforms, isn't `/var/log` a Linux thing?
You could also choose to not mention the location. 
> What about using `show variables like 'log_error';`?
If I am correct, the mariadb server is not running at that moment (script is preparing data dir) so I guess this is not possible.
> Why is it using `/var/lib` for logs on non-Debian platforms, isn't `/var/log` a Linux thing?
Good Q. There must be a reason but I don't know.
> You could also choose to not mention the location.
That may be a solution, not very user friendly though.
Is it the script or the server that writes to the log?
I assume it's the server. Maybe it should write to stdout / stderr (in addition to the log)?
Hi,
so the script is calling mysqld_install_cmd_line(), which is calling mysqld with some options
mysqld_install_cmd_line()
|
{
|
"$mysqld_bootstrap" $defaults $defaults_group_suffix "$mysqld_opt" --bootstrap $silent_startup\
|
"--basedir=$basedir" "--datadir=$ldata" --log-warnings=0 --enforce-storage-engine="" \
|
"--plugin-dir=${plugindir}" \
|
$args --max_allowed_packet=8M \
|
--net_buffer_length=16K
|
}
|
Note that above there is no log_error server option.
Based on log_error server variable if the server is started without --log-error errors should be in stderr.
If there is no name (of a file for this option) logs will be in <hostname.err> in the datadir (since $ldata == datadir in your case in /var/lib/mysql).
So in your case the error logs will be in stderr already you can try to find out does it exist.
Even the server code is saying the same:
case OPT_LOG_ERROR:
|
/*
|
"No --log-error" == "write errors to stderr",
|
"--log-error without argument" == "write errors to a file".
|
*/
|
Note that if you have a config file (see option files that is configuring log_error) it can be invoked from there also.
In debian there is postinst script that is using hardcoded value for logs {{mysql_logdir=/var/log/mysql }}.
I think that correct patch for this case is to write Examine the logs in stderr for more information. - since log_error="" and parsing the arguments is already finished before!
But let's wait on danblack review too.
it generally sounds better to use log-error is stderr immediately since is already quietened already.
dbdeployer seems to cover the init with --no-defaults https://github.com/datacharmer/dbdeployer/blob/6c64381704783784d164adf865ae02ed907c2c09/sandbox/sandbox.go#L812 so I assume this is stderr already, datacharmer do you have an opinion here?
containter usage of mysql_install_db will process stderr in the logs of the container execution so that use is ok.
The last option that I'd rather avoid is to look at the /proc/
{pid}/fd/3 (not BSD friendly) symlink during bootstrap to see where its being written to.
As written, going to get tests written first MDEV-24268
dbdeployer uses --no-defaults to prevent the sandboxed server from being
hijacked by existing my.cnf in the recognized paths.
As for the output, mysql_install_db writes regular messages to stdout, and
only errors to stderr.
The error log is defined in the configuration file (my.sandbox.cnf) but
since we use --no-defaults, the output of errors goes to stderr, and it
gets displayed to users if mysql_install_db exits with a non-zero code.
On Tue, Nov 24, 2020 at 6:27 AM Daniel Black (Jira) <jira@mariadb.org>
PR for review https://github.com/MariaDB/server/pull/2363
Note Debian downstream will still need to pass --log-error on their cmd line in the post-install. Maybe its useful if that is kept different to the user default as its packaging related and reading the error log of the previous combined with the current would be less readable.