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

plugin variables conflict with bootstrap (debian mariadb-server-10.0.postinst)

Details

    • 10.1.9-1, 10.1.9-2

    Description

      Having a plugin variable in my.cnf, like query_response_time_stats=ON from the query response time plugin, prevents a mysql upgrade.

      # aptitude install mariadb-server-10.0
      The following partially installed packages will be configured:
        mariadb-server mariadb-server-10.0 
      No packages will be installed, upgraded, or removed.
      0 packages upgraded, 0 newly installed, 0 to remove and 33 not upgraded.
      Need to get 0 B of archives. After unpacking 0 B will be used.
      Setting up mariadb-server-10.0 (10.0.20+maria-1~wheezy) ...
      [ ok ] Stopping MariaDB database server: mysqld.
      dpkg: error processing mariadb-server-10.0 (--configure):
       subprocess installed post-installation script returned error exit status 7
      dpkg: dependency problems prevent configuration of mariadb-server:
       mariadb-server depends on mariadb-server-10.0 (= 10.0.20+maria-1~wheezy); however:
        Package mariadb-server-10.0 is not configured yet.
       
      dpkg: error processing mariadb-server (--configure):
       dependency problems - leaving unconfigured
      Errors were encountered while processing:
       mariadb-server-10.0
       mariadb-server
      E: Sub-process /usr/bin/dpkg returned an error code (1)
      A package failed to install.  Trying to recover:
      Setting up mariadb-server-10.0 (10.0.20+maria-1~wheezy) ...
      [ ok ] Stopping MariaDB database server: mysqld.
      dpkg: error processing mariadb-server-10.0 (--configure):
       subprocess installed post-installation script returned error exit status 7
      dpkg: dependency problems prevent configuration of mariadb-server:
       mariadb-server depends on mariadb-server-10.0 (= 10.0.20+maria-1~wheezy); however:
        Package mariadb-server-10.0 is not configured yet.
       
      dpkg: error processing mariadb-server (--configure):
       dependency problems - leaving unconfigured
      Errors were encountered while processing:
       mariadb-server-10.0
       mariadb-server

      using:
      export DEBIAN_SCRIPT_DEBUG=1
      aptitude install mariadb-server-10.0

      ....
      ....
      ....
      ++ /bin/echo -e 'USE mysql;\n' 'CREATE TABLE IF NOT EXISTS plugin (name char(64) COLLATE utf8_bin NOT NULL DEFAULT '\'''\'', ' '  dl char(128) COLLATE utf8_bin NOT NULL DEFAULT '\'''\'', ' '  PRIMARY KEY (name)) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='\''MySQL plugins'\'';'
      + install_plugins='USE mysql;
       CREATE TABLE IF NOT EXISTS plugin (name char(64) COLLATE utf8_bin NOT NULL DEFAULT '\'''\'',    dl char(128) COLLATE utf8_bin NOT NULL DEFAULT '\'''\'',    PRIMARY KEY (name)) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='\''MySQL plugins'\'';'
      + echo 'USE mysql;
       ALTER TABLE user CHANGE Password Password char(41) character set latin1 collate latin1_bin DEFAULT '\'''\'' NOT NULL;'
      + /usr/sbin/mysqld --bootstrap --user=mysql --disable-log-bin --skip-grant-tables --default-storage-engine=myisam
      + logger -p daemon.err -t mysqld_safe -i
      dpkg: error processing mariadb-server-10.0 (--configure):
       subprocess installed post-installation script returned error exit status 7
      dpkg: dependency problems prevent configuration of mariadb-server:
       mariadb-server depends on mariadb-server-10.0 (= 10.0.20+maria-1~wheezy); however:
        Package mariadb-server-10.0 is not configured yet

      so failure is where it tried to bootstrap the server.

      The error log shows the complaint about an unidentified server variable, understandable when no plugins are loaded.

      Jul  9 06:14:40 media1 mysqld_safe[17874]: 150709  6:14:40 [Note] /usr/sbin/mysqld (mysqld 10.0.20-MariaDB-1~wheezy-log) starting as process 17905 ...
      Jul  9 06:14:40 media1 mysqld_safe[17874]: 150709  6:14:40 [Note] InnoDB: Using mutexes to ref count buffer pool pages
      Jul  9 06:14:40 media1 mysqld_safe[17874]: 150709  6:14:40 [Note] InnoDB: The InnoDB memory heap is disabled
      Jul  9 06:14:40 media1 mysqld_safe[17874]: 150709  6:14:40 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
      Jul  9 06:14:40 media1 mysqld_safe[17874]: 150709  6:14:40 [Note] InnoDB: Memory barrier is not used
      Jul  9 06:14:40 media1 mysqld_safe[17874]: 150709  6:14:40 [Note] InnoDB: Compressed tables use zlib 1.2.7
      Jul  9 06:14:40 media1 mysqld_safe[17874]: 150709  6:14:40 [Note] InnoDB: Using Linux native AIO
      Jul  9 06:14:40 media1 mysqld_safe[17874]: 150709  6:14:40 [Note] InnoDB: Using CPU crc32 instructions
      Jul  9 06:14:40 media1 mysqld_safe[17874]: 150709  6:14:40 [Note] InnoDB: Initializing buffer pool, size = 8.0G
      Jul  9 06:14:41 media1 mysqld_safe[17874]: 150709  6:14:41 [Note] InnoDB: Completed initialization of buffer pool
      Jul  9 06:14:41 media1 mysqld_safe[17874]: 150709  6:14:41 [Note] InnoDB: Highest supported file format is Barracuda.
      Jul  9 06:14:42 media1 mysqld_safe[17874]: 150709  6:14:42 [Note] InnoDB: 128 rollback segment(s) are active.
      Jul  9 06:14:42 media1 mysqld_safe[17874]: 150709  6:14:42 [Note] InnoDB: Waiting for purge to start
      Jul  9 06:14:42 media1 mysqld_safe[17874]: 150709  6:14:42 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 1381243811209
      Jul  9 06:14:42 media1 mysqld_safe[17874]: 2015-07-09 06:14:42 7fe2f07f8700 InnoDB: Loading buffer pool(s) from /srv/mysql/ib_buffer_pool
      Jul  9 06:14:42 media1 mysqld_safe[17874]: 2015-07-09 06:14:42 7fe2f07f8700 InnoDB: Buffer pool(s) load completed at 150709  6:14:42
      Jul  9 06:14:42 media1 mysqld_safe[17874]: 150709  6:14:42 [ERROR] /usr/sbin/mysqld: unknown variable 'query_response_time_stats=ON'
      Jul  9 06:14:42 media1 mysqld_safe[17874]: 150709  6:14:42 [ERROR] Aborting
      Jul  9 06:14:42 media1 mysqld_safe[17874]: 
      Jul  9 06:14:42 media1 mysqld_safe[17874]: 150709  6:14:42 [Note] InnoDB: FTS optimize thread exiting.
      Jul  9 06:14:42 media1 mysqld_safe[17874]: 150709  6:14:42 [Note] InnoDB: Starting shutdown...
      Jul  9 06:14:42 media1 mysqld_safe[17874]: 2015-07-09 06:14:42 7fe2f07f8700 InnoDB: Dumping buffer pool(s) to /srv/mysql/ib_buffer_pool
      Jul  9 06:14:42 media1 mysqld_safe[17874]: 2015-07-09 06:14:42 7fe2f07f8700 InnoDB: Buffer pool(s) dump completed at 150709  6:14:42
      Jul  9 06:14:45 media1 mysqld_safe[17874]: 150709  6:14:45 [Note] InnoDB: Shutdown completed; log sequence number 1381243811219
      Jul  9 06:14:45 media1 mysqld_safe[17874]: 150709  6:14:45 [Note] /usr/sbin/mysqld: Shutdown complete

      Removing the query_response_time_stats=ON from the config file was able to package configure and complete the server upgrade. I also hit this on 10.0.19 on a RHEL server too.

      Possible solutions:
      a) bootstrap ignores vars it doesn't understand
      b) additional mysqld argument to ignore unrecognised vars.
      c) moving plugin vars to

      {mariadb,mariadb-10.0,server,mysqld,client-server}

      -plugins section (probably too ugly)

      Attachments

        Issue Links

          Activity

            danblack Daniel Black created issue -

            The (a) solution raises the question why server is not allowed to ignore unknown variables at the first place. If it's considered too dangerous, probably for bootstrap it is too.
            The existing workaround with 'loose-' prefix seems more flexible than (b) – it allows to select which unrecognized options can be bypassed, rather than do it unconditionally.
            The (c) solution, in addition to very likely human errors, might cause problems, because as I understand bootstrap only ignores plugins from mysql.plugin, while those requested via plugin-load are still loaded, and skipping their variables might be undesirable.

            That said, both (a) and (b) are still viable. Assigning to serg for a decision.

            elenst Elena Stepanova added a comment - The (a) solution raises the question why server is not allowed to ignore unknown variables at the first place. If it's considered too dangerous, probably for bootstrap it is too. The existing workaround with 'loose-' prefix seems more flexible than (b) – it allows to select which unrecognized options can be bypassed, rather than do it unconditionally. The (c) solution, in addition to very likely human errors, might cause problems, because as I understand bootstrap only ignores plugins from mysql.plugin, while those requested via plugin-load are still loaded, and skipping their variables might be undesirable. That said, both (a) and (b) are still viable. Assigning to serg for a decision.
            elenst Elena Stepanova made changes -
            Field Original Value New Value
            Fix Version/s 10.1 [ 16100 ]
            Affects Version/s 10.1 [ 16100 ]
            Affects Version/s 10.0 [ 16000 ]
            Affects Version/s 5.5 [ 15800 ]
            Affects Version/s 10.0.20 [ 19201 ]
            Assignee Sergei Golubchik [ serg ]
            elenst Elena Stepanova made changes -
            Status Open [ 1 ] Confirmed [ 10101 ]
            elenst Elena Stepanova made changes -
            Summary plugin variables conflict with debian mariadb-server-10.0.postinst plugin variables conflict with bootstrap (debian mariadb-server-10.0.postinst)
            danblack Daniel Black added a comment -

            as a limited version of a), could ignore variables beginning with the select name from mysql.plugin name while in --bootstrap mode.

            danblack Daniel Black added a comment - as a limited version of a), could ignore variables beginning with the select name from mysql.plugin name while in --bootstrap mode.
            danblack Daniel Black added a comment -

            note - this actually prevents upgrades and its very hard from the description of the package failure to trace it back to the original cause.

            danblack Daniel Black added a comment - note - this actually prevents upgrades and its very hard from the description of the package failure to trace it back to the original cause.
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.1.8-2 [ 14 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked lower
            ratzpo Rasmus Johansson (Inactive) made changes -
            Assignee Sergei Golubchik [ serg ] Sergey Vojtovich [ svoj ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.1.8-2 [ 14 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked higher
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.1.9 [ 18 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked lower

            serg, please review 2 patches for this bug.

            svoj Sergey Vojtovich added a comment - serg , please review 2 patches for this bug.
            svoj Sergey Vojtovich made changes -
            Assignee Sergey Vojtovich [ svoj ] Sergei Golubchik [ serg ]
            Status Confirmed [ 10101 ] In Review [ 10002 ]
            svoj Sergey Vojtovich made changes -
            svoj Sergey Vojtovich made changes -
            svoj Sergey Vojtovich made changes -
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.1.9-1 [ 18 ] 10.1.9-1, 10.1.9-2 [ 18, 19 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked higher
            serg Sergei Golubchik made changes -
            Assignee Sergei Golubchik [ serg ] Sergey Vojtovich [ svoj ]
            Status In Review [ 10002 ] Stalled [ 10000 ]
            serg Sergei Golubchik added a comment - - edited

            svoj, these patches are ok, but as far as I can see they don't fix the reported issue.

            serg Sergei Golubchik added a comment - - edited svoj , these patches are ok, but as far as I can see they don't fix the reported issue.
            svoj Sergey Vojtovich made changes -
            svoj Sergey Vojtovich made changes -

            Fixed by removing failing command from postinst script.

            svoj Sergey Vojtovich added a comment - Fixed by removing failing command from postinst script.
            svoj Sergey Vojtovich made changes -
            Component/s Platform Debian [ 10136 ]
            Fix Version/s 10.1.9 [ 20301 ]
            Fix Version/s 10.1 [ 16100 ]
            Resolution Fixed [ 1 ]
            Status Stalled [ 10000 ] Closed [ 6 ]
            elenst Elena Stepanova made changes -
            Katiushyn Pavel Katiushyn added a comment - - edited

            It does not seem that the bug is fixed.
            Can it be re-opened and fixed?
            The problem was experienced on MariaDB 10.1.26 with audit plugin installed:

            2017-09-22 10:11:39 140626245846976 [ERROR] mysqld: unknown variable 'server_audit_excl_users=user1,user2'
            2017-09-22 10:11:39 140626245846976 [ERROR] Aborting
            

            Katiushyn Pavel Katiushyn added a comment - - edited It does not seem that the bug is fixed. Can it be re-opened and fixed? The problem was experienced on MariaDB 10.1.26 with audit plugin installed: 2017-09-22 10:11:39 140626245846976 [ERROR] mysqld: unknown variable 'server_audit_excl_users=user1,user2' 2017-09-22 10:11:39 140626245846976 [ERROR] Aborting

            Katiushyn, did you get the above from Debian postinst script?

            svoj Sergey Vojtovich added a comment - Katiushyn , did you get the above from Debian postinst script?

            No. I had postinst script error with MariaDB 10.1.22 or 10.1.21. And just tried to start "mysqld --bootstrap" with 10.1.26.
            But after your comment, I tried to upgrade 10.1.25 to 10.1.26 and it work well. So it is fixed indeed.
            So, please ignore my comment above: either it was those version problem or I my mistake during upgrade.

            Katiushyn Pavel Katiushyn added a comment - No. I had postinst script error with MariaDB 10.1.22 or 10.1.21. And just tried to start "mysqld --bootstrap" with 10.1.26. But after your comment, I tried to upgrade 10.1.25 to 10.1.26 and it work well. So it is fixed indeed. So, please ignore my comment above: either it was those version problem or I my mistake during upgrade.
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 70520 ] MariaDB v4 [ 149345 ]

            People

              svoj Sergey Vojtovich
              danblack Daniel Black
              Votes:
              1 Vote for this issue
              Watchers:
              6 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.