• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login

    MySQL problem continues

    Scheduled Pinned Locked Moved
    Linux Problems
    3
    6
    4.5k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • R
      rhythmtone
      last edited by

      Ubuntu 14.04 x64 FOG 1.1.0

      Using the above software versions, MySQL continues to be a problem and just fails randomly. This command doesn’t help, but it does show the problem:

      sudo /etc/init.d/mysql restart

      • Stopping MySQL database server mysqld [ OK ]
      • Starting MySQL database server mysqld [fail]

      When this happens the web browser interface re-directs back to the Schema Updater:
      [url]http://1.1.1.1/fog/[/url] ------> re-directs to -------->
      [url]http://1.1.1.1/fog/commons/schemaupdater/index.php?redir=1[/url]

      In FOG version 1.1.0, when you click “Install/Upgrade Now” it says “Update/Install Failed!” and “The following errors occurred”, followed by a huge text output of error messages.

      My question is: Would it be useful to post this error log to the FOG forums, or is this just something that is a broken MySQL problem?

      Thanks,
      D.L.

      1 Reply Last reply Reply Quote 0
      • JunkhackerJ
        Junkhacker Developer
        last edited by

        if you get a huge text of errors from an attempted schema update, the cause is usually an incorrect mysql password in your config.php file

        signature:
        Junkhacker
        We are here to help you. If you are unresponsive to our questions, don't expect us to be responsive to yours.

        1 Reply Last reply Reply Quote 0
        • R
          rhythmtone
          last edited by

          Hi, thanks for the reply,
          I’ve checked that and the MySQL password is correct. I know that this isn’t the problem because the FOG server works fine on boot up, but starts re-directing back to the schema update page at a random interval of time - essentially MySQL is failing after some random amount of time.

          Since this command fails to restart MySQL, I know that there’s something wrong…
          sudo /etc/init.d/mysql restart

          Somewhere in another thread Tom mentioned that it is probably a Ubuntu problem with 14.04 but I just thought that I would ask if I should post the error log…

          I’m thinking that no password on the MySQL database might fix the problem, but I really want to have a password going forward.

          Thanks!
          D.L.

          1 Reply Last reply Reply Quote 0
          • Tom ElliottT
            Tom Elliott
            last edited by

            I don’t think a “nopassword” setting will work.

            If you want to post the mysql.log file that might help see the error, could you also get a portion of the syslog from around the time when mysql fails?

            Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.

            Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

            Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

            1 Reply Last reply Reply Quote 0
            • R
              rhythmtone
              last edited by

              Thanks for the reply,

              Which system log should I use, and/or where would I find it?? I know that there are several in Ubuntu…

              Below are the SQL logs…

              From /var/log/mysql -> error.log

              140606 09:35:05 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
              140606 9:35:38 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
              140606 9:35:38 [Note] Plugin ‘FEDERATED’ is disabled.
              140606 9:35:38 InnoDB: The InnoDB memory heap is disabled
              140606 9:35:38 InnoDB: Mutexes and rw_locks use GCC atomic builtins
              140606 9:35:38 InnoDB: Compressed tables use zlib 1.2.8
              140606 9:35:38 InnoDB: Using Linux native AIO
              140606 9:35:38 InnoDB: Initializing buffer pool, size = 128.0M
              140606 9:35:38 InnoDB: Completed initialization of buffer pool
              140606 9:35:38 InnoDB: highest supported file format is Barracuda.
              140606 9:35:39 InnoDB: Waiting for the background threads to start
              140606 09:35:40 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
              140606 9:35:40 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
              140606 9:35:40 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
              140606 9:35:40 [Note] Plugin ‘FEDERATED’ is disabled.
              140606 9:35:40 InnoDB: The InnoDB memory heap is disabled
              140606 9:35:40 InnoDB: Mutexes and rw_locks use GCC atomic builtins
              140606 9:35:40 InnoDB: Compressed tables use zlib 1.2.8
              140606 9:35:40 InnoDB: Using Linux native AIO
              140606 9:35:40 InnoDB: Initializing buffer pool, size = 128.0M
              140606 9:35:40 InnoDB: Completed initialization of buffer pool
              InnoDB: Unable to lock ./ibdata1, error: 11
              InnoDB: Check that you do not already have another mysqld process
              InnoDB: using the same InnoDB data or log files.
              140606 9:35:40 InnoDB: Retrying to lock the first data file
              140606 9:35:40 InnoDB: 5.5.37 started; log sequence number 1676069
              140606 9:35:40 [Note] Server hostname (bind-address): ‘127.0.0.1’; port: 3306
              140606 9:35:40 [Note] - ‘127.0.0.1’ resolves to ‘127.0.0.1’;
              140606 9:35:40 [Note] Server socket created on IP: ‘127.0.0.1’.
              140606 9:35:41 [Note] Event Scheduler: Loaded 0 events
              140606 9:35:41 [Note] /usr/sbin/mysqld: ready for connections.
              Version: ‘5.5.37-0ubuntu0.14.04.1’ socket: ‘/var/run/mysqld/mysqld.sock’ port: 3306 (Ubuntu)
              InnoDB: Unable to lock ./ibdata1, error: 11
              InnoDB: Check that you do not already have another mysqld process
              InnoDB: using the same InnoDB data or log files.
              InnoDB: Unable to lock ./ibdata1, error: 11
              InnoDB: Check that you do not already have another mysqld process
              InnoDB: using the same InnoDB data or log files.
              InnoDB: Unable to lock ./ibdata1, error: 11
              InnoDB: Check that you do not already have another mysqld process
              InnoDB: using the same InnoDB data or log files.
              InnoDB: Unable to lock ./ibdata1, error: 11
              InnoDB: Check that you do not already have another mysqld process
              InnoDB: using the same InnoDB data or log files.
              140606 9:37:20 InnoDB: Unable to open the first data file
              InnoDB: Error in opening ./ibdata1
              140606 9:37:20 InnoDB: Operating system error number 11 in a file operation.
              InnoDB: Error number 11 means ‘Resource temporarily unavailable’.
              InnoDB: Some operating system error numbers are described at
              InnoDB: [url]http://dev.mysql.com/doc/refman/5.5/en/operating-system-error-codes.html[/url]
              140606 9:37:20 InnoDB: Could not open or create data files.
              140606 9:37:20 InnoDB: If you tried to add new data files, and it failed here,
              140606 9:37:20 InnoDB: you should now edit innodb_data_file_path in my.cnf back
              140606 9:37:20 InnoDB: to what it was, and remove the new ibdata files InnoDB created
              140606 9:37:20 InnoDB: in this failed attempt. InnoDB only wrote those files full of
              140606 9:37:20 InnoDB: zeros, but did not yet use them in any way. But be careful: do not
              140606 9:37:20 InnoDB: remove old data files which contain your precious data!
              140606 9:37:20 [ERROR] Plugin ‘InnoDB’ init function returned error.
              140606 9:37:20 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
              140606 9:37:20 [ERROR] Unknown/unsupported storage engine: InnoDB
              140606 9:37:20 [ERROR] Aborting

              140606 9:37:20 [Note] /usr/sbin/mysqld: Shutdown complete

              140606 09:37:20 mysqld_safe Number of processes running now: 0
              140606 09:37:20 mysqld_safe mysqld restarted
              140606 9:37:20 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
              140606 9:37:20 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
              140606 9:37:20 [Note] Plugin ‘FEDERATED’ is disabled.
              140606 9:37:20 InnoDB: The InnoDB memory heap is disabled
              140606 9:37:20 InnoDB: Mutexes and rw_locks use GCC atomic builtins
              140606 9:37:20 InnoDB: Compressed tables use zlib 1.2.8
              140606 9:37:20 InnoDB: Using Linux native AIO
              140606 9:37:20 InnoDB: Initializing buffer pool, size = 128.0M
              140606 9:37:20 InnoDB: Completed initialization of buffer pool
              InnoDB: Unable to lock ./ibdata1, error: 11
              InnoDB: Check that you do not already have another mysqld process
              InnoDB: using the same InnoDB data or log files.
              140606 9:37:20 InnoDB: Retrying to lock the first data file
              InnoDB: Unable to lock ./ibdata1, error: 11
              InnoDB: Check that you do not already have another mysqld process
              InnoDB: using the same InnoDB data or log files.
              InnoDB: Unable to lock ./ibdata1, error: 11
              InnoDB: Check that you do not already have another mysqld process
              InnoDB: using the same InnoDB data or log files.

              From /var/log/upstart -> mysql.log

              140606 9:35:38 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
              /usr/bin/mysqladmin: connect to server at ‘localhost’ failed
              error: ‘Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)’
              Check that mysqld is running and that the socket: ‘/var/run/mysqld/mysqld.sock’ exists!
              /usr/bin/mysqladmin: connect to server at ‘localhost’ failed
              error: ‘Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)’
              Check that mysqld is running and that the socket: ‘/var/run/mysqld/mysqld.sock’ exists!
              /usr/bin/mysqladmin: connect to server at ‘localhost’ failed
              error: ‘Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)’
              Check that mysqld is running and that the socket: ‘/var/run/mysqld/mysqld.sock’ exists!
              mysqld is alive
              Checking for tables which need an upgrade, are corrupt or were
              not closed cleanly.

              1 Reply Last reply Reply Quote 0
              • R
                rhythmtone
                last edited by

                Hi,
                Apparently a “no password” setting does fix this issue across the board, reliably, every time.

                I would much rather have a password in my situation, that is my goal.

                The strangest thing is how it happens randomly - my new FOG installations have been fine being up all weekend, but I’m guessing that sometime this week it will happen again…

                Thanks for any help and/or advice,
                D.L.

                1 Reply Last reply Reply Quote 0
                • 1 / 1
                • First post
                  Last post

                188

                Online

                12.0k

                Users

                17.3k

                Topics

                155.2k

                Posts
                Copyright © 2012-2024 FOG Project