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

Unneccesary error message when shutting down MariaDB

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Not a Bug
    • Affects Version/s: 5.5.40
    • Fix Version/s: N/A
    • Component/s: Platform Debian
    • Labels:
      None

      Description

      I'm using MariaDB 5.5.40-0ubuntu0.14.04.1 on Ubuntu 14.04. According to Launchpad bugs are tracked here, so if this is distribution specific let me know where I should file this.

      vagrant@vagrant:/etc/init.d$ sudo service mysql start
       * Starting MariaDB database server mysqld   [ OK ]
       * Checking for corrupt, not cleanly closed and upgrade needing tables.
      vagrant@vagrant:/etc/init.d$ sudo /usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf --verbose shutdown
      Shutdown signal sent to server;  Waiting for pid file to disappear
      ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
      

      I'm not sure why the error is being thrown, given that the entire point of the command is to shutdown MariaDB. As is, it's confusing when sudo service mysql shutdown / restart throws errors that don't actually reflect an error.

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            elenst Elena Stepanova added a comment -

            I am not getting the error message with the same package.
            Is it reproducible for you? Could you please attach your cnf file(s) – all of them, just in case? Of course, the passwords should be removed or obfuscated.

            Show
            elenst Elena Stepanova added a comment - I am not getting the error message with the same package. Is it reproducible for you? Could you please attach your cnf file(s) – all of them, just in case? Of course, the passwords should be removed or obfuscated.
            Hide
            deviantintegral Andrew Berry added a comment -

            I think there might be a connection to the size of the database. On a fresh VM I can only replicate this if I run the command with:

            sudo service mysql start; sudo /usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf --verbose shutdown

            Here's the configs, but they are unmodified from what is shipped.

            Show
            deviantintegral Andrew Berry added a comment - I think there might be a connection to the size of the database. On a fresh VM I can only replicate this if I run the command with: sudo service mysql start; sudo /usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf --verbose shutdown Here's the configs, but they are unmodified from what is shipped.
            Hide
            elenst Elena Stepanova added a comment -

            Thanks, now I understand what the problem is. It's important that you run shutdown soon after the server startup.

            When the server on debian gets started, the startup script exits as soon as the server becomes available. However, before exiting it starts several background jobs (checkups, basically) which can take time and can be done in parallel with normal server activity. Each checkup involves connecting to the server.
            You stop the server while these jobs are still running, so the next one cannot connect to the server. The message that you see is not really issued by mysqladmin (you can make sure of that yourself by redirecting its output to a file), it comes from the background job which failed.

            I think it's a corner case and basically harmless, so I would vote for leaving it as is since tampering with the debian magic often ends up painfully. Please comment if you disagree and think it should be fixed.

            Show
            elenst Elena Stepanova added a comment - Thanks, now I understand what the problem is. It's important that you run shutdown soon after the server startup. When the server on debian gets started, the startup script exits as soon as the server becomes available. However, before exiting it starts several background jobs (checkups, basically) which can take time and can be done in parallel with normal server activity. Each checkup involves connecting to the server. You stop the server while these jobs are still running, so the next one cannot connect to the server. The message that you see is not really issued by mysqladmin (you can make sure of that yourself by redirecting its output to a file), it comes from the background job which failed. I think it's a corner case and basically harmless, so I would vote for leaving it as is since tampering with the debian magic often ends up painfully. Please comment if you disagree and think it should be fixed.
            Hide
            deviantintegral Andrew Berry added a comment -

            Where this gets confusing is when other programs are using the service commands to start and shutdown the server. For example, in https://github.com/Lullabot/lmm this comes up often when you check out the wrong mysql branch by mistake. A user will immediately run another checkout command issuing a server stop before the background checks are complete, causing this error.

            Is there already a way to check for the status of these background jobs outside of the service command? Or a way to start the server so it blocks until the checks are complete?

            Show
            deviantintegral Andrew Berry added a comment - Where this gets confusing is when other programs are using the service commands to start and shutdown the server. For example, in https://github.com/Lullabot/lmm this comes up often when you check out the wrong mysql branch by mistake. A user will immediately run another checkout command issuing a server stop before the background checks are complete, causing this error. Is there already a way to check for the status of these background jobs outside of the service command? Or a way to start the server so it blocks until the checks are complete?
            Hide
            elenst Elena Stepanova added a comment -

            Hi,

            These jobs aren't really hardcoded, they are open for fine-tuning by an admin.
            If you look at /etc/init.d/mysql, after server startup it runs the additional script:

                        if mysqld_status check_alive warn; then
                            log_end_msg 0
                            # Now start mysqlcheck or whatever the admin wants.
                            output=$(/etc/mysql/debian-start)
                            [ -n "$output" ] && log_action_msg "$output"
            

            So you can turn it off entirely right there. Or, you can go to /etc/mysql/debian-start and reconfigure it any way you prefer:

            trap "" SIGHUP
            (
              upgrade_system_tables_if_necessary;
              check_root_accounts;
              check_for_crashed_tables;
            ) >&2 &
            

            If you remove sending it to background, I suppose it will work kind of you meant by "it blocks until the checks are complete". Or, if you redirect output of the checks into separate file(s), you can monitor them from there without getting weird messages in the console; etc.

            Show
            elenst Elena Stepanova added a comment - Hi, These jobs aren't really hardcoded, they are open for fine-tuning by an admin. If you look at /etc/init.d/mysql, after server startup it runs the additional script: if mysqld_status check_alive warn; then log_end_msg 0 # Now start mysqlcheck or whatever the admin wants. output=$(/etc/mysql/debian-start) [ -n "$output" ] && log_action_msg "$output" So you can turn it off entirely right there. Or, you can go to /etc/mysql/debian-start and reconfigure it any way you prefer: trap "" SIGHUP ( upgrade_system_tables_if_necessary; check_root_accounts; check_for_crashed_tables; ) >&2 & If you remove sending it to background, I suppose it will work kind of you meant by "it blocks until the checks are complete". Or, if you redirect output of the checks into separate file(s), you can monitor them from there without getting weird messages in the console; etc.
            Hide
            elenst Elena Stepanova added a comment -

            According to the comments above, closing it as not-a-bug for now. Please comment if you disagree.

            Show
            elenst Elena Stepanova added a comment - According to the comments above, closing it as not-a-bug for now. Please comment if you disagree.
            Hide
            deviantintegral Andrew Berry added a comment -

            Agreed, this is fine to close. I did find that it was the upgrade_system_tables_if_necessary function that was taking most of the background job time. I will probably fork the startup script into LMM directly so we can tweak the startup commands.

            Thanks for your help!

            Show
            deviantintegral Andrew Berry added a comment - Agreed, this is fine to close. I did find that it was the upgrade_system_tables_if_necessary function that was taking most of the background job time. I will probably fork the startup script into LMM directly so we can tweak the startup commands. Thanks for your help!

              People

              • Assignee:
                elenst Elena Stepanova
                Reporter:
                deviantintegral Andrew Berry
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: