mysql服务无法启动/挂起 - 超时(Ubuntu,MariaDB)

时间:2021-09-13 18:22:02

I set up my first Ubuntu Server with Ubuntu 16.04, nginx, php7.0, MariaDB, nextcloud and external DynDNS yesterday (used this Tutorial: https://www.rosehosting.com/blog/install-nextcloud-on-ubuntu-16-04/). Everything worked fine but since I restarted the server today nextcloud just shows me a blank page. After clicking through all logs of nginx, MariaDB and nextcloud I found out that the mysql service just doesn't start. So run service mysql start and everything worked fine again (calling nextcloud from server as well as other workstations). I just wondered that the terminal didn't "close" the line. Like it was still working on the command. After about 5 minutes the line "closes" and the message

我昨天用Ubuntu 16.04,nginx,php7.0,MariaDB,nextcloud和外部DynDNS设置了我的第一个Ubuntu服务器(使用本教程:https://www.rosehosting.com/blog/install-nextcloud-on-ubuntu-16 -04 /)。一切正常,但自从我今天重新启动服务器后,nextcloud只显示了一个空白页面。点击nginx,MariaDB和nextcloud的所有日志后,我发现mysql服务无法启动。所以运行服务mysql start并且一切正常(从服务器和其他工作站调用nextcloud)。我只是想知道终端没有“关闭”线路。就像它仍然在执行命令。大约5分钟后,线路“关闭”并显示消息

"Job for mariadb.service failed because a timeout was exceeded. See "systemctl status mariadb.service" and "journalctl -xe" for details."

“mariadb.service的作业因超时而失败。有关详细信息,请参阅”systemctl status mariadb.service“和”journalctl -xe“。

appears (see below). Then the clients again just get a blank page in nextcloud. When I run the command and close the Terminal immediately clients get access as well but loose it after 5 minutes.

出现(见下文)。然后客户再次在nextcloud中得到一个空白页面。当我运行命令并关闭终端时,客户端也可以立即访问,但在5分钟后将其松开。

I tried backing up the nextcloud sql and run apt-get purge --auto-remove mariadb-server. Then again the MariaDB installation steps out of the Tutorial with importing the backup sql instead of creating a new one. Didn't change everything.

我尝试备份nextcloud sql并运行apt-get purge --auto-remove mariadb-server。然后,MariaDB安装步骤退出教程,导入备份sql而不是创建新的。没有改变一切。

Next try was update-rc.d mysql defaults and update-rc.d mysql enable. But after a restart just the blank page again. Access is only possible for 5 minutes by starting the service manual.

接下来尝试的是update-rc.d mysql defaults和update-rc.d mysql enable。但重新启动后再次只是空白页。只需启动服务手册,即可访问5分钟。

I also tried the BUM - BootUpManager but the service seems to be anabled. I saw you can start services out oft it manually as well. So tried it with mysql and surprise: nextcloud available for 5 minutes while BUM just hangs up :D

我也尝试了BUM - BootUpManager,但服务似乎是可行的。我看到你也可以手动启动服务。所以尝试用mysql和惊喜:nextcloud可用5分钟,而BUM只是挂起:D

I found mariadb.com/kb/en/mariadb/starting-and-stopping-mariadb-automatically/ as well but tried nothing of it because it seems like there is somthing else really wrong.

我发现了mariadb.com/kb/en/mariadb/starting-and-stopping-mariadb-automatically/但是没有尝试过它,因为它似乎还有其他错误。

root@s1:~# systemctl status mariadb.service:

root @ s1:〜#systemctl status mariadb.service:

\u25cf mariadb.service - MariaDB database server
   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: 
  Drop-In: /etc/systemd/system/mariadb.service.d
           \u2514\u2500migrated-from-my.cnf-settings.conf
   Active: failed (Result: timeout) since Di 2016-12-06 14:52:51 CET; 55s ago
  Process: 3565 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WS
  Process: 3415 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR
  Process: 3409 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START
  Process: 3405 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/ru
 Main PID: 3565 (code=exited, status=0/SUCCESS)

Dez 06 14:52:48 s1 mysqld[3565]: 2016-12-06 14:52:48 3067387712 [Note] /usr/sbin
Dez 06 14:52:48 s1 mysqld[3565]: 2016-12-06 14:52:48 3067387712 [Note] Event Sch
Dez 06 14:52:48 s1 mysqld[3565]: 2016-12-06 14:52:48 2147785536 [Note] InnoDB: F
Dez 06 14:52:48 s1 mysqld[3565]: 2016-12-06 14:52:48 3067387712 [Note] InnoDB: S
Dez 06 14:52:49 s1 mysqld[3565]: 2016-12-06 14:52:49 3067387712 [Note] InnoDB: W
Dez 06 14:52:50 s1 mysqld[3565]: 2016-12-06 14:52:50 3067387712 [Note] InnoDB: S
Dez 06 14:52:50 s1 mysqld[3565]: 2016-12-06 14:52:50 3067387712 [Note] /usr/sbin
Dez 06 14:52:51 s1 systemd[1]: Failed to start MariaDB database server.
Dez 06 14:52:51 s1 systemd[1]: mariadb.service: Unit entered failed state.
Dez 06 14:52:51 s1 systemd[1]: mariadb.service: Failed with result 'timeout'.

root@s1:~# journalctl -xe:

root @ s1:〜#journalctl -xe:

Dez 06 14:52:48 s1 mysqld[3565]: 2016-12-06 14:52:48 3067387712 [Note] Event Scheduler: Purging the queue. 0 events
Dez 06 14:52:48 s1 mysqld[3565]: 2016-12-06 14:52:48 2147785536 [Note] InnoDB: FTS optimize thread exiting.
Dez 06 14:52:48 s1 mysqld[3565]: 2016-12-06 14:52:48 3067387712 [Note] InnoDB: Starting shutdown...
Dez 06 14:52:49 s1 mysqld[3565]: 2016-12-06 14:52:49 3067387712 [Note] InnoDB: Waiting for page_cleaner to finish flushing of buffer po
Dez 06 14:52:50 s1 mysqld[3565]: 2016-12-06 14:52:50 3067387712 [Note] InnoDB: Shutdown completed; log sequence number 111890806
Dez 06 14:52:50 s1 mysqld[3565]: 2016-12-06 14:52:50 3067387712 [Note] /usr/sbin/mysqld: Shutdown complete
Dez 06 14:52:50 s1 audit[3648]: AVC apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profi
Dez 06 14:52:50 s1 kernel: audit: type=1400 audit(1481032370.973:29): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - 
Dez 06 14:52:50 s1 audit[3565]: AVC apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profi
Dez 06 14:52:50 s1 kernel: audit: type=1400 audit(1481032370.973:30): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - 
Dez 06 14:52:51 s1 systemd[1]: Failed to start MariaDB database server.
-- Subject: Unit mariadb.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit mariadb.service has failed.
-- 
-- The result is failed.
Dez 06 14:52:51 s1 systemd[1]: mariadb.service: Unit entered failed state.
Dez 06 14:52:51 s1 systemd[1]: mariadb.service: Failed with result 'timeout'.
Dez 06 14:54:54 s1 x11vnc[2665]: 06/12/2016 14:54:54 cursor_noshape_updates_clients: 1
Dez 06 14:55:16 s1 ntpd[1244]: 46.4.1.155 local addr 192.168.178.50 -> <null>
Dez 06 14:57:30 s1 ntpd[1244]: 89.238.66.98 local addr 192.168.178.50 -> <null>

Content in /ect/init.d (if useful):

/ect/init.d中的内容(如果有用):

#!/bin/bash
#
### BEGIN INIT INFO
# Provides:          mysql
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Should-Start:      $network $named $time
# Should-Stop:       $network $named $time
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start and stop the mysql database server daemon
# Description:       Controls the main MariaDB database server daemon "mysqld"
#                    and its wrapper script "mysqld_safe".
### END INIT INFO
#
set -e
set -u
${DEBIAN_SCRIPT_DEBUG:+ set -v -x}

test -x /usr/sbin/mysqld || exit 0

. /lib/lsb/init-functions

SELF=$(cd $(dirname $0); pwd -P)/$(basename $0)
CONF=/etc/mysql/my.cnf
MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf"

# priority can be overriden and "-s" adds output to stderr
ERR_LOGGER="logger -p daemon.err -t /etc/init.d/mysql -i"

# Safeguard (relative paths, core dumps..)
cd /
umask 077

# mysqladmin likes to read /root/.my.cnf. This is usually not what I want
# as many admins e.g. only store a password without a username there and
# so break my scripts.
export HOME=/etc/mysql/

# Source default config file.
[ -r /etc/default/mariadb ] && . /etc/default/mariadb

## Fetch a particular option from mysql's invocation.
#
# Usage: void mysqld_get_param option
mysqld_get_param() {
    /usr/sbin/mysqld --print-defaults \
        | tr " " "\n" \
        | grep -- "--$1" \
        | tail -n 1 \
        | cut -d= -f2
}

## Do some sanity checks before even trying to start mysqld.
sanity_checks() {
  # check for config file
  if [ ! -r /etc/mysql/my.cnf ]; then
    log_warning_msg "$0: WARNING: /etc/mysql/my.cnf cannot be read. See README.Debian.gz"
    echo                "WARNING: /etc/mysql/my.cnf cannot be read. See README.Debian.gz" | $ERR_LOGGER
  fi

  # check for diskspace shortage
  datadir=`mysqld_get_param datadir`
  if LC_ALL=C BLOCKSIZE= df --portability $datadir/. | tail -n 1 | awk '{ exit ($4>4096) }'; then
    log_failure_msg "$0: ERROR: The partition with $datadir is too full!"
    echo                "ERROR: The partition with $datadir is too full!" | $ERR_LOGGER
    exit 1
  fi
}

## Checks if there is a server running and if so if it is accessible.
#
# check_alive insists on a pingable server
# check_dead also fails if there is a lost mysqld in the process list
#
# Usage: boolean mysqld_status [check_alive|check_dead] [warn|nowarn]
mysqld_status () {
    ping_output=`$MYADMIN ping 2>&1`; ping_alive=$(( ! $? ))

    ps_alive=0
    pidfile=`mysqld_get_param pid-file`
    if [ -f "$pidfile" ] && ps `cat $pidfile` >/dev/null 2>&1; then ps_alive=1; fi

    if [ "$1" = "check_alive"  -a  $ping_alive = 1 ] ||
       [ "$1" = "check_dead"   -a  $ping_alive = 0  -a  $ps_alive = 0 ]; then
    return 0 # EXIT_SUCCESS
    else
    if [ "$2" = "warn" ]; then
        echo -e "$ps_alive processes alive and '$MYADMIN ping' resulted in\n$ping_output\n" | $ERR_LOGGER -p daemon.debug
    fi
    return 1 # EXIT_FAILURE
    fi
}

#
# main()
#

case "${1:-''}" in
  'start')
    sanity_checks;
    # Start daemon
    log_daemon_msg "Starting MariaDB database server" "mysqld"
    if mysqld_status check_alive nowarn; then
       log_progress_msg "already running"
       log_end_msg 0
    else
        # Could be removed during boot
        test -e /var/run/mysqld || install -m 755 -o mysql -g root -d /var/run/mysqld

        # Start MariaDB! 
        /usr/bin/mysqld_safe "${@:2}" > /dev/null 2>&1 &

        # 6s was reported in #352070 to be too little
        for i in $(seq 1 "${MYSQLD_STARTUP_TIMEOUT:-60}"); do
                sleep 1
            if mysqld_status check_alive nowarn ; then break; fi
        log_progress_msg "."
        done
        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"
        else
            log_end_msg 1
        log_failure_msg "Please take a look at the syslog"
        fi
    fi
    ;;

  'stop')
    # * As a passwordless mysqladmin (e.g. via ~/.my.cnf) must be possible
    # at least for cron, we can rely on it here, too. (although we have 
    # to specify it explicit as e.g. sudo environments points to the normal
    # users home and not /root)
    log_daemon_msg "Stopping MariaDB database server" "mysqld"
    if ! mysqld_status check_dead nowarn; then
      set +e
      shutdown_out=`$MYADMIN shutdown 2>&1`; r=$?
      set -e
      if [ "$r" -ne 0 ]; then
        log_end_msg 1
        [ "$VERBOSE" != "no" ] && log_failure_msg "Error: $shutdown_out"
        log_daemon_msg "Killing MariaDB database server by signal" "mysqld"
        killall -15 mysqld
            server_down=
        for i in `seq 1 600`; do
              sleep 1
              if mysqld_status check_dead nowarn; then server_down=1; break; fi
            done
          if test -z "$server_down"; then killall -9 mysqld; fi
      fi
        fi

        if ! mysqld_status check_dead warn; then
      log_end_msg 1
      log_failure_msg "Please stop MariaDB manually and read /usr/share/doc/mariadb-server-10.1/README.Debian.gz!"
      exit -1
    else
      log_end_msg 0
        fi
    ;;

  'restart')
    set +e; $SELF stop; set -e
    $SELF start 
    ;;

  'reload'|'force-reload')
    log_daemon_msg "Reloading MariaDB database server" "mysqld"
    $MYADMIN reload
    log_end_msg 0
    ;;

  'status')
    if mysqld_status check_alive nowarn; then
      log_action_msg "$($MYADMIN version)"
    else
      log_action_msg "MariaDB is stopped."
      exit 3
    fi
    ;;

  'bootstrap')
    # Bootstrap the cluster, start the first node
    # that initiates the cluster
    log_daemon_msg "Bootstrapping the cluster" "mysqld"
    $SELF start "${@:2}" --wsrep-new-cluster
    ;;

  *)
    echo "Usage: $SELF start|stop|restart|reload|force-reload|status|bootstrap"
    exit 1
    ;;
esac

Unfortunately Google can't help me. I trid to explain as much as I can maybe this helps you helping me. Thanks a lot!

不幸的是谷歌无法帮助我。我尽可能多地解释,这可以帮助你帮助我。非常感谢!

5 个解决方案

#1


6  

FYI:

In my case neither the solution of Vincent or Lw Bi worked exactly, I needed some further actions.

在我的情况下,Vincent或Lw Bi的解决方案都没有完全正常工作,我需要采取进一步的行动。

Disabling the profile through placing a link in /etc/apparmor.d/disable/ simply didn't work, I don't know why.

通过在/etc/apparmor.d/disable/中放置链接来禁用配置文件根本不起作用,我不知道为什么。

On the other hand, setting MySQL to complain mode didn't work either immediately.

另一方面,将MySQL设置为抱怨模式也不会立即生效。

:~$ sudo aa-complain /usr/sbin/mysqld

Setting /usr/sbin/mysqld to complain mode.

将/ usr / sbin / mysqld设置为抱怨模式。

ERROR: /etc/apparmor.d/usr.sbin.mysqld contains no profile

I needed to add the lines:

我需要添加以下行:

/usr/sbin/mysqld {
}

to /etc/apparmor.d/usr.sbin.mysqld, and then I could set it to complain mode successfully.

到/etc/apparmor.d/usr.sbin.mysqld,然后我可以成功将其设置为抱怨模式。

#2


5  

Long question for nothing... Never heard of AppArmor but it was the reasen. The answer here fixed it. Don't care about apparmor's ERROR the profile wouldn't exist.

无所事事的长期问题......从来没有听说过AppArmor,但它是reasen。这里的答案修正了它。不关心apparmor的ERROR配置文件不存在。

sudo aa-status shows you what apparmor is doing; what actually has an enforced policy, versus what's just set to complain.

sudo aa-status显示了apparmor正在做什么;什么实际上有一个强制执行的政策,而不是刚刚抱怨的。

sudo apt-get install apparmor-utils adds a few commands that make the apparmor profiles easier to deal with, such as...

sudo apt-get install apparmor-utils添加了一些命令,使apparmor配置文件更容易处理,例如...

sudo aa-complain /usr/sbin/mysqld turns the profile from "enforce" to complain. (aa-enforce turns it back.)

sudo aa-complain / usr / sbin / mysqld将配置文件从“强制执行”变为抱怨。 (aa-enforce将其转回。)

Once that's done, sudo service apparmor reload restarts apparmor, and voila... sudo /etc/init.d/mysql start works, and the server stays up.

一旦完成,sudo服务apparmor重新加载重新启动apparmor,瞧... sudo /etc/init.d/mysql启动工作,服务器保持运行状态。

#3


3  

Moving mysqld to "complain" group was not enough in my case (MariaDB 10.1.21 running on Ubuntu 16.04). I had to fully disable apparmor for mysqld:

将mysqld移动到“抱怨”组是不够的(在Ubuntu 16.04上运行的MariaDB 10.1.21)。我不得不完全禁用mysqld的apparmor:

sudo ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/ 
sudo service apparmor reload
sudo service mysql restart

Now everything works fine.

现在一切正常。

#4


2  

Please note that since 10.1.10, MariaDB uses systemd to start the service. If you have tried MYSQLD_STARTUP_TIMEOUT and it has not worked, you are probably using this or a later version. The /etc/init.d/mysql script is no longer used, so MYSQLD_STARTUP_TIMEOUT has no effect.

请注意,从10.1.10开始,MariaDB使用systemd启动服务。如果您已经尝试过MYSQLD_STARTUP_TIMEOUT并且它没有工作,那么您可能正在使用此版本或更高版本。不再使用/etc/init.d/mysql脚本,因此MYSQLD_STARTUP_TIMEOUT无效。

You need to find your mariadb.service file. In our case, it did not contain a timeout so the MariaDB default was being used. Just add:

您需要找到您的mariadb.service文件。在我们的例子中,它没有超时,因此使用了MariaDB默认值。只需添加:

TimeoutStartSec = 0

TimeoutStartSec = 0

In the [Service] section, and it will never time out.

在[服务]部分,它永远不会超时。

It would be a good idea to create your own config file containing this so it doesn't get overwritten by later re-installs.

最好创建一个包含此文件的配置文件,这样以后重新安装就不会覆盖它。

On ubuntu 18.04, you will fine this file in

在ubuntu 18.04上,你将在这个文件中使用

/lib/systemd/system/mariadb.service

Put your own file in

把你自己的文件放进去

/etc/systemd/system/mariadb.service.d

Remember to run systemctl daemon-reload after adding the timeout somewhere (and maybe check /var/log/syslog to see if the reload was successful), otherwise your time out will be ignored.

记得在某处添加超时后运行systemctl守护进程重新加载(也可以检查/ var / log / syslog以查看重载是否成功),否则将忽略超时。

#5


1  

Run the following commands:

运行以下命令:

sudo dpkg --configure -a
sudo service mysql start

#1


6  

FYI:

In my case neither the solution of Vincent or Lw Bi worked exactly, I needed some further actions.

在我的情况下,Vincent或Lw Bi的解决方案都没有完全正常工作,我需要采取进一步的行动。

Disabling the profile through placing a link in /etc/apparmor.d/disable/ simply didn't work, I don't know why.

通过在/etc/apparmor.d/disable/中放置链接来禁用配置文件根本不起作用,我不知道为什么。

On the other hand, setting MySQL to complain mode didn't work either immediately.

另一方面,将MySQL设置为抱怨模式也不会立即生效。

:~$ sudo aa-complain /usr/sbin/mysqld

Setting /usr/sbin/mysqld to complain mode.

将/ usr / sbin / mysqld设置为抱怨模式。

ERROR: /etc/apparmor.d/usr.sbin.mysqld contains no profile

I needed to add the lines:

我需要添加以下行:

/usr/sbin/mysqld {
}

to /etc/apparmor.d/usr.sbin.mysqld, and then I could set it to complain mode successfully.

到/etc/apparmor.d/usr.sbin.mysqld,然后我可以成功将其设置为抱怨模式。

#2


5  

Long question for nothing... Never heard of AppArmor but it was the reasen. The answer here fixed it. Don't care about apparmor's ERROR the profile wouldn't exist.

无所事事的长期问题......从来没有听说过AppArmor,但它是reasen。这里的答案修正了它。不关心apparmor的ERROR配置文件不存在。

sudo aa-status shows you what apparmor is doing; what actually has an enforced policy, versus what's just set to complain.

sudo aa-status显示了apparmor正在做什么;什么实际上有一个强制执行的政策,而不是刚刚抱怨的。

sudo apt-get install apparmor-utils adds a few commands that make the apparmor profiles easier to deal with, such as...

sudo apt-get install apparmor-utils添加了一些命令,使apparmor配置文件更容易处理,例如...

sudo aa-complain /usr/sbin/mysqld turns the profile from "enforce" to complain. (aa-enforce turns it back.)

sudo aa-complain / usr / sbin / mysqld将配置文件从“强制执行”变为抱怨。 (aa-enforce将其转回。)

Once that's done, sudo service apparmor reload restarts apparmor, and voila... sudo /etc/init.d/mysql start works, and the server stays up.

一旦完成,sudo服务apparmor重新加载重新启动apparmor,瞧... sudo /etc/init.d/mysql启动工作,服务器保持运行状态。

#3


3  

Moving mysqld to "complain" group was not enough in my case (MariaDB 10.1.21 running on Ubuntu 16.04). I had to fully disable apparmor for mysqld:

将mysqld移动到“抱怨”组是不够的(在Ubuntu 16.04上运行的MariaDB 10.1.21)。我不得不完全禁用mysqld的apparmor:

sudo ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/ 
sudo service apparmor reload
sudo service mysql restart

Now everything works fine.

现在一切正常。

#4


2  

Please note that since 10.1.10, MariaDB uses systemd to start the service. If you have tried MYSQLD_STARTUP_TIMEOUT and it has not worked, you are probably using this or a later version. The /etc/init.d/mysql script is no longer used, so MYSQLD_STARTUP_TIMEOUT has no effect.

请注意,从10.1.10开始,MariaDB使用systemd启动服务。如果您已经尝试过MYSQLD_STARTUP_TIMEOUT并且它没有工作,那么您可能正在使用此版本或更高版本。不再使用/etc/init.d/mysql脚本,因此MYSQLD_STARTUP_TIMEOUT无效。

You need to find your mariadb.service file. In our case, it did not contain a timeout so the MariaDB default was being used. Just add:

您需要找到您的mariadb.service文件。在我们的例子中,它没有超时,因此使用了MariaDB默认值。只需添加:

TimeoutStartSec = 0

TimeoutStartSec = 0

In the [Service] section, and it will never time out.

在[服务]部分,它永远不会超时。

It would be a good idea to create your own config file containing this so it doesn't get overwritten by later re-installs.

最好创建一个包含此文件的配置文件,这样以后重新安装就不会覆盖它。

On ubuntu 18.04, you will fine this file in

在ubuntu 18.04上,你将在这个文件中使用

/lib/systemd/system/mariadb.service

Put your own file in

把你自己的文件放进去

/etc/systemd/system/mariadb.service.d

Remember to run systemctl daemon-reload after adding the timeout somewhere (and maybe check /var/log/syslog to see if the reload was successful), otherwise your time out will be ignored.

记得在某处添加超时后运行systemctl守护进程重新加载(也可以检查/ var / log / syslog以查看重载是否成功),否则将忽略超时。

#5


1  

Run the following commands:

运行以下命令:

sudo dpkg --configure -a
sudo service mysql start