Uploaded image for project: 'Modules'
  1. Modules
  2. MODULES-7219

puppetlabs/mysql : service mysql restart fails after install with override_options

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open
    • Priority: Normal
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: mysql
    • Labels:
    • Environment:
      • Ubuntu 16.04
      • mariadb-server-10.1
    • Template:
      MODULES Bug Template
    • Acceptance Criteria:
      Hide

      Changes to the my.cnf config file that occur directly after an installation of mysql server should trigger a restart of the mysql server after which the config changes are applied and in effect, in case the parameter restart => true is set.

      Show
      Changes to the my.cnf config file that occur directly after an installation of mysql server should trigger a restart of the mysql server after which the config changes are applied and in effect, in case the parameter restart => true is set.
    • Epic Link:
    • Team:
      Modules
    • Method Found:
      Needs Assessment
    • QA Risk Assessment:
      Needs Assessment

      Description

      After installation of the mariadb-server-10.1 package using the ::mysql::server class, the contents of /etc/mysql/my.cnf are changed using the override_options param. This should trigger a restart of the mysql service (when providing the restart => true param.

      The code looks like this:

       

      class { '::mysql::server':
        package_name     => 'mariadb-server-10.1',
        service_name     => 'mysql',
        restart          => true,
        override_options => {
          'mysqld' => {
            'bind-address' => '0.0.0.0'
          }
        }
      }
      

       

      The output of the puppet run shows that indeed a refresh of Service[mysqld] is triggered but somehow the actual restart of the service does not occur. When testing the result of the puppet run, the bind-address option is not working. Only after an (explicit) restart of the mysql service will the bind-address option be working, after which we are able to connect to the mariadb-server from outside the localhost.

      Here is the relevant part of the puppet output:

      Notice: /Stage[main]/Mysql::Server::Install/Package[mysql-server]/ensure: created
      Notice: /Stage[main]/Mysql::Server::Install/Package[mysql-server]/ensure: created
      Notice: /Stage[main]/Mysql::Server::Config/File[mysql-config-file]/content:
      --- /etc/mysql/my.cnf 2018-05-08 01:28:15.000000000 +0000
      +++ /tmp/puppet-file20180529-13226-1esvyxf 2018-05-29 07:41:19.144394000 +0000
      @@ -1,189 +1,63 @@
      -# MariaDB database server configuration file.
      ...
      -!includedir /etc/mysql/conf.d/
      +!includedir /etc/mysql/conf.d
      +
       
      Notice: /Stage[main]/Mysql::Server::Config/File[mysql-config-file]/content: content changed '{md5}272b568cc9fc1ccc5d01b200df3cd73a' to '{md5}999050414f1a8d515f4a432b15e99e1a'
      Info: Class[Mysql::Server::Config]: Scheduling refresh of Class[Mysql::Server::Service]
      Notice: /Stage[main]/Mysql::Server::Installdb/File[/var/log/mysql/error.log]/ensure: created
      Info: Class[Mysql::Server::Service]: Scheduling refresh of Service[mysqld]
      Info: Class[Mysql::Server::Service]: Scheduling refresh of Exec[wait_for_mysql_socket_to_open]
      Notice: /Stage[main]/Mysql::Server::Service/Service[mysqld]/ensure: ensure changed 'stopped' to 'running'
      Info: /Stage[main]/Mysql::Server::Service/Service[mysqld]: Unscheduling refresh on Service[mysqld]
      Notice: /Stage[main]/Mysql::Server::Service/Exec[wait_for_mysql_socket_to_open]: Triggered 'refresh' from 1 event

       

      Here is some syslog output:

      //During mariadb-server install (service started by package manager)
      May 29 07:41:15 vagrant mysqld[19923]: 2018-05-29  7:41:15 140375843199232 [Note] /usr/sbin/mysqld: ready for connections.
      May 29 07:41:15 vagrant mysqld[19923]: Version: '10.1.33-MariaDB-1~xenial'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution
      May 29 07:41:15 vagrant mysqld[19953]: Checking for corrupt, not cleanly closed and upgrade needing tables.
      May 29 07:41:15 vagrant systemd[1]: Started MariaDB 10.1.33 database server.
      May 29 07:41:15 vagrant systemd[1]: Reloading.
      May 29 07:41:15 vagrant systemd[1]: Started ACPI event daemon.
      May 29 07:41:18 vagrant dhclient[1344]: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 14 (xid=0x3302d909)
      May 29 07:41:19 vagrant puppet-agent[13226]: (/Stage[main]/Mysql::Server::Install/Package[mysql-server]/ensure) created
       
      //After config file changes
      May 29 07:41:19 vagrant systemd[1]: Reloading.
      May 29 07:41:19 vagrant systemd[1]: Started ACPI event daemon.
      May 29 07:41:19 vagrant systemd[1]: Started MariaDB 10.1.33 database server.
      May 29 07:41:19 vagrant puppet-agent[13226]: (/Stage[main]/Mysql::Server::Service/Service[mysqld]/ensure) ensure changed 'stopped' to 'running'

      It can be seen from the syslog output that the mariadb-server is started for the first time after installation by the package manager. This service start is not managed by puppet.

      Later after the config file changes a refresh of the Service[mysqld] resource is triggered, and the puppet output says changed 'stopped' to 'running'. Although the server was already running, puppet thinks it's changed from stopped to running. In the syslog output it can also be seen that the mysql server is not stopped after the config file changes. The syslog output only says 'Started MariaDB...'

      The issue is that the refresh of Serivce[mysqld] after config changes has no effect and the new config values are not applied. I'm not sure if this issue can be solved in the puppetlabs/mysql module or if it's something that occurs in the puppet core code.

      I suspect that the issue is not specifically related to mariadb-server, although I have not tested this.

       

       

       

       

       

       

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned
              Reporter:
              theodorus Theo van Oostrum
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:

                  Zendesk Support