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

log-basename unpredictable behavior in standalone mode

    Details

      Description

      Hello,
      We are trying to unify all our setups/configurations with the help of:

      datadir = /var/lib/mysql
      log-basename=mariadb
      

      However, we've hit the unpredictable behavior (in 5.5.41) in Standalone mode:

      Our syslog configuration:

      [mysqld_safe]
      syslog
      syslog-tag=daemon
      

      Host: MARIADBTEST

      The tests we've run on CentOS 6.6:

      With Standalone Server [mysqld]:

      1. No syslog
      mariadb.err
      mariadb-slow.log
      MARIADBTEST.pid

      Result: log-basename doesn't affect pid file name.

      2. Adding log_error='' in standalone mode (trying to activate syslog):
      mariadb-slow.log
      MARIADBTEST.err
      MARIADBTEST.pid

      Result: no syslog logging is active, and both err and pid files use hostname.

      With mysqld_multi [mysqld1]:

      1. No syslog
      mariadb.err
      mariadb.pid
      mariadb-slow.log

      Result: everything is good!

      2. Adding log_error='' (trying to activate syslog):
      mariadb.pid
      mariadb-slow.log

      Result: Everything is good, and error log goes to syslog!

      As you see only in mysqld_multi mode the behavior is by design.

      Thanks!
      Alex

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            elenst Elena Stepanova added a comment -

            What kind of server startup you mean when you are talking about a standalone server? Do you use mysqld_safe, or start mysqld binary directly?

            Show
            elenst Elena Stepanova added a comment - What kind of server startup you mean when you are talking about a standalone server? Do you use mysqld_safe, or start mysqld binary directly?
            Hide
            ShivaS Alex added a comment -

            I mean the conventional way to start/use MariaDB (with mysqld_safe , [mysqld] section in /etc/my.cnf and init control (/etc/init.d/mysql)).

            Show
            ShivaS Alex added a comment - I mean the conventional way to start/use MariaDB (with mysqld_safe , [mysqld] section in /etc/my.cnf and init control (/etc/init.d/mysql)).
            Hide
            ShivaS Alex added a comment -

            Also, just checked MariaDB10, same behavior ;(

            Show
            ShivaS Alex added a comment - Also, just checked MariaDB10, same behavior ;(
            Hide
            elenst Elena Stepanova added a comment - - edited

            Thanks for the clarification.

            So, there are several issues in here.

            1. pidfile name does not use log-basename – it's a problem of the startup script (/etc/init.d/mysql), at least on RPM-based systems. At some point it checks if a path to the pid file is set explicitly, and if not, sets it to <hostname>.pid. It has no notion of log-basename.

            2. no syslog if log-basename is given – it's a problem of mysqld_safe. It does have a notion of log-basename, and if it finds it among the options, it sets a value for the error log file name accordingly. But later it uses this variable to check whether the variable is set, assuming it was done by the user, and if it's not empty, the script claims that the user provided wrong configuration – set the error log name and requested syslog at the same time (the output of mysqld_safe says just that: "Can't log to error log and syslog at the same time..."

            Since both bugs are outside the server, apparently mysqld_multi is not anyhow affected by them, hence it behaves correctly.
            It's awful that historically there are so many steps in the process where the values are used and modified, it has always been a big welcome for all kinds of bugs.

            3. The behavior with the empty error log – it's arguably acceptable, the expectations are vague here and might depend on the order of the given options. On one hand, when the value is empty, it's supposed to be set to <hostname>.err; on the other hand, log-basename is expected to modify the prefix. I wouldn't want any changes to be made for this special case unless you think it's certainly incorrect and have a good suggestion on how to make it consistent.

            Show
            elenst Elena Stepanova added a comment - - edited Thanks for the clarification. So, there are several issues in here. 1. pidfile name does not use log-basename – it's a problem of the startup script (/etc/init.d/mysql), at least on RPM-based systems. At some point it checks if a path to the pid file is set explicitly, and if not, sets it to <hostname>.pid. It has no notion of log-basename. 2. no syslog if log-basename is given – it's a problem of mysqld_safe. It does have a notion of log-basename, and if it finds it among the options, it sets a value for the error log file name accordingly. But later it uses this variable to check whether the variable is set, assuming it was done by the user, and if it's not empty, the script claims that the user provided wrong configuration – set the error log name and requested syslog at the same time (the output of mysqld_safe says just that: "Can't log to error log and syslog at the same time..." Since both bugs are outside the server, apparently mysqld_multi is not anyhow affected by them, hence it behaves correctly. It's awful that historically there are so many steps in the process where the values are used and modified, it has always been a big welcome for all kinds of bugs. 3. The behavior with the empty error log – it's arguably acceptable, the expectations are vague here and might depend on the order of the given options. On one hand, when the value is empty, it's supposed to be set to <hostname>.err; on the other hand, log-basename is expected to modify the prefix. I wouldn't want any changes to be made for this special case unless you think it's certainly incorrect and have a good suggestion on how to make it consistent.
            Hide
            ShivaS Alex added a comment -

            Hi Elena, you are right! I've reviewed it again and rechecked mysql init and mysqld_safe scripts.
            While pid file can be explicitly mentioned in my.cnf (or a patch with my_print_defaults introduced) , the combination of both log-basename and syslog variables is a real show stopper.
            I don't want to touch mysqld_safe for now as there could be some intentional logic to avoid conflicts that I am unaware about.

            I am leaving it to MariaDB team to decide what's next
            We'll keep using all logs/pids explicitly defined in my.cnf for now because we use syslog everywhere, except for a few cases where we use mysqld_multi.

            p.s. Maybe it's about time to consolidate mysqld_multi and mysqld_safe into something smarter, just to avoid fixing legacy bugs of both scripts

            Thanks!
            Alex

            Show
            ShivaS Alex added a comment - Hi Elena, you are right! I've reviewed it again and rechecked mysql init and mysqld_safe scripts. While pid file can be explicitly mentioned in my.cnf (or a patch with my_print_defaults introduced) , the combination of both log-basename and syslog variables is a real show stopper. I don't want to touch mysqld_safe for now as there could be some intentional logic to avoid conflicts that I am unaware about. I am leaving it to MariaDB team to decide what's next We'll keep using all logs/pids explicitly defined in my.cnf for now because we use syslog everywhere, except for a few cases where we use mysqld_multi. p.s. Maybe it's about time to consolidate mysqld_multi and mysqld_safe into something smarter, just to avoid fixing legacy bugs of both scripts Thanks! Alex

              People

              • Assignee:
                serg Sergei Golubchik
                Reporter:
                ShivaS Alex
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 1 hour
                  1h