it-swarm.com.de

mySQL-Dienst startet nicht/hängt auf - Timeout (Ubuntu, MariaDB)

Ich habe meinen ersten Ubuntu-Server gestern mit Ubuntu 16.04, nginx, php7.0, MariaDB, nextcloud und externem DynDNS eingerichtet (verwendet dieses Tutorial: https://www.rosehosting.com/blog/install-nextcloud-on-ubuntu -16-04/ ). Alles klappte, aber seit ich den Server heute neu gestartet habe, zeigt nextcloud mir nur eine leere Seite. Nachdem ich alle Protokolle von nginx, MariaDB und nextcloud durchgeklickt hatte, stellte ich fest, dass der mysql-Dienst einfach nicht startet. Führen Sie service mysql start aus und alles funktionierte wieder einwandfrei (Aufruf nextcloud vom Server sowie von anderen Arbeitsstationen). Ich habe mich nur gewundert, dass das Terminal die Leitung nicht "geschlossen" hat. Als würde es immer noch am Befehl arbeiten. Nach etwa 5 Minuten "schließt" die Zeile und die Nachricht 

"Der Job für mariadb.service ist fehlgeschlagen, da ein Timeout überschritten wurde. Weitere Informationen finden Sie unter " Systemctl status mariadb.service "und" journalctl -xe "."

erscheint (siehe unten). Dann bekommen die Kunden in nextcloud nur noch eine leere Seite. Wenn ich den Befehl ausführen und das Terminal schließe, erhalten die Clients sofort Zugriff, verlieren es jedoch nach 5 Minuten. 

Ich habe versucht, die nextcloud sql zu sichern und apt-get purge --auto-remove mariadb-server auszuführen. Dann führt die Installation von MariaDB aus dem Lernprogramm mit dem Importieren der Sicherungsdatei statt einer neuen Erstellung aus. Hat nicht alles verändert.

Der nächste Versuch war update-rc.d mysql defaults und update-rc.d mysql enable. Aber nach einem Neustart nur noch die leere Seite. Der Zugriff ist nur für 5 Minuten durch Starten des Service-Handbuchs möglich. 

Ich habe auch den BUM - BootUpManager ausprobiert, aber der Dienst scheint aktiviert zu sein. Ich habe gesehen, dass Sie die Dienste auch manuell starten können. Also mit Mysql und Überraschung probiert: nextcloud für 5 Minuten verfügbar, während BUM auflegt: D 

Ich habe mariadb.com/kb/de/mariadb/startingundstoppmariadb-automatically/ auch gefunden, aber nichts ausprobiert, weil es so aussieht, als ob etwas anderes wirklich falsch ist. 

[email protected]:~# 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'.

[email protected]:~# 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>

Inhalt in /ect/init.d (falls nützlich):

#!/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

Google kann mir leider nicht helfen. Ich habe versucht, so viel wie möglich zu erklären, vielleicht hilft Ihnen das dabei, mir zu helfen. Danke vielmals!

8
Lw Bi

Lange Frage nach nichts ... Ich habe noch nie von AppArmor gehört, aber es war der Grund. Die Antwort hier reparierte es. Kümmern Sie sich nicht um den ERROR des Apparmors, das Profil würde nicht existieren.

Sudo aa-status zeigt Ihnen, was Apparmor gerade macht. was hat eigentlich ein erzwungene Politik im Vergleich zu dem, was sich gerade beschwert.

Sudo apt-get install apparmor-utils fügt einige Befehle hinzu, die die .__ ausmachen. Einfacher zu handhabende Apparmor-Profile wie ...

Sudo aa-complain /usr/sbin/mysqld wandelt das Profil von "Durchsetzen" in .__ um. beschweren. (aa-force setzt es zurück.)

Sobald dies erledigt ist, startet Sudo service apparmor reload den Apparmor neu und voila ... Sudo /etc/init.d/mysql start funktioniert, und der Server bleibt aktiv.

4
Lw Bi

Falls Sie von diesem Fehler gebissen werden, wird die Lösung im Fehlerbericht als Vorschlag angegeben:

  1. echo "/usr/sbin/mysqld { }" > /etc/apparmor.d/usr.sbin.mysqld
  2. apparmor_parser -v -R /etc/apparmor.d/usr.sbin.mysqld
  3. systemctl restart mariadb

Hintergrund

Wenn Sie zuvor MySQL installiert hatten, wurde ein AppArmor-Profil aktiviert, das nicht mit MariaDB kompatibel ist. apt-get remove --purge entfernt nur das Profil, deaktiviert/entlädt es jedoch nicht. Durch manuelles Entladen kann MariaDB ungehindert von AppArmor ausgeführt werden.

26
quazgar

Diese letzte Option funktionierte für mich (von Quazgar). Ich habe Ubuntu 18.10 mit MariaDB 10.3.13 installiert:

$ echo "/usr/sbin/mysqld { }" > /etc/apparmor.d/usr.sbin.mysqld
$ apparmor_parser -v -R /etc/apparmor.d/usr.sbin.mysqld
$ systemctl restart mariadb

Ich musste "Sudo su" verwenden, damit es funktioniert.

10
Gert Kruger

Zu Ihrer Information:

In meinem Fall funktionierte weder die Lösung von Vincent noch Lw Bi genau, ich brauchte weitere Maßnahmen.

Das Deaktivieren des Profils durch Platzieren eines Links in /etc/apparmor.d/disable/ hat einfach nicht funktioniert. Ich weiß nicht warum.

Andererseits hat das Einstellen des MySQL-Modus auf den Reklamationsmodus ebenfalls nicht sofort funktioniert.

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

/usr/sbin/mysqld in den Reklamationsmodus setzen.

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

Ich musste die Zeilen hinzufügen:

/usr/sbin/mysqld {
}

auf /etc/apparmor.d/usr.sbin.mysqld, und dann konnte ich den Reklamationsmodus erfolgreich einstellen.

6
kerzane

Das Verschieben von mysqld in die Gruppe "beschweren" reichte in meinem Fall nicht aus (MariaDB 10.1.21 unter Ubuntu 16.04). Ich musste apparmor für mysqld vollständig deaktivieren:

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

Jetzt funktioniert alles gut.

4
Vincent

Bitte beachten Sie, dass MariaDB seit 10.1.10 systemd zum Starten des Dienstes verwendet. Wenn Sie MYSQLD_STARTUP_TIMEOUT ausprobiert haben und dies nicht funktioniert hat, verwenden Sie wahrscheinlich diese oder eine neuere Version. Das Skript /etc/init.d/mysql wird nicht mehr verwendet, daher hat MYSQLD_STARTUP_TIMEOUT keine Auswirkungen.

Sie müssen Ihre mariadb.service-Datei finden. In unserem Fall enthielt es kein Timeout, daher wurde der MariaDB-Standard verwendet. Einfach hinzufügen:

TimeoutStartSec = 0

Im Abschnitt [Service] wird es nie zu einem Timeout kommen.

Es empfiehlt sich, eine eigene Konfigurationsdatei zu erstellen, die diese Datei enthält, damit sie bei späteren Neuinstallationen nicht überschrieben wird.

Am ubuntu 18.04 werden Sie diese Datei in ordnen 

/lib/systemd/system/mariadb.service

Legen Sie Ihre eigene Datei ein

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

Denken Sie daran, systemctl daemon-reload auszuführen, nachdem Sie das Timeout irgendwo hinzugefügt haben (und überprüfen Sie ggf./var/log/syslog, ob das Reload erfolgreich war). Andernfalls wird Ihr Timeout ignoriert.

2
Dave Hindle

Führen Sie die folgenden Befehle aus:

Sudo dpkg --configure -a
Sudo service mysql start
1
Mahbub

Das hat bei mir funktioniert:

Die Korrektur hat bei mir nicht funktioniert.

$ Sudo aa-complain/usr/sbin/mysqld Einstellung von/usr/sbin/mysqld auf Beschwerde-Modus.

FEHLER: /etc/apparmor.d/usr.sbin.mysqld enthält kein Profil. Also ich Das Profil wurde deaktiviert (mit aa-disable, was der Lösung von plutocrat entspricht)

$ Sudo aa-disable/usr/sbin/mysqld Deaktivieren von/usr/sbin/mysqld. ICH mysqld-akonadi und mysqld-digikam sind ebenfalls deaktiviert.

Ein Apparmor-Reload war nicht genug, also musste ich neu starten und mariadb hat ganz gut angefangen.

Quelle: https://askubuntu.com/a/964928/106100

0
Meetai.com