Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-18591

mysql_install_db wrong output message for error logs

Details

    Description

      Hi,
      if the mysql_install_db command fails it says:

      Installation of system tables failed!  Examine the logs in /var/lib/mysql for more information.
      

      On Debian the error log goes by default to /var/log/mysql/error.log and not into /var/lib/mysql.
      Faustin

      Attachments

        Activity

          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.

          anel Anel Husakovic added a comment - 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.
          danblack Daniel Black added a comment -

          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

          danblack Daniel Black added a comment - 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>

          datacharmer Giuseppe Maxia added a comment - 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>
          danblack Daniel Black added a comment - PR for review https://github.com/MariaDB/server/pull/2363
          danblack Daniel Black added a comment -

          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.

          danblack Daniel Black added a comment - 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.

          People

            danblack Daniel Black
            faust Faustin Lammler
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.