web-dev-qa-db-fra.com

le service mysql ne parvient pas à démarrer/raccroche - délai d'attente (Ubuntu, MariaDB)

J'ai configuré mon premier serveur Ubuntu avec Ubuntu 16.04, nginx, php7.0, MariaDB, nextcloud et DynDNS externe hier (utilisé ce tutoriel: https://www.rosehosting.com/blog/install-nextcloud-on-ubuntu -16-04/ ). Tout a bien fonctionné, mais depuis que j'ai redémarré le serveur aujourd'hui, nextcloud me montre simplement une page vierge. Après avoir cliqué sur tous les journaux de nginx, MariaDB et nextcloud, j'ai découvert que le service mysql ne démarre tout simplement pas. Donc, lancez service mysql start et tout fonctionne à nouveau correctement (en appelant nextcloud depuis le serveur et d’autres stations de travail). Je me demandais simplement que le terminal ne "ferme" pas la ligne. Comme s'il travaillait toujours sur la commande. Après environ 5 minutes, la ligne "se ferme" et le message 

"La tâche pour mariadb.service a échoué car un délai a été dépassé. Voir " Systemctl status mariadb.service "et" journalctl -xe "pour plus de détails."

apparaît (voir ci-dessous). Ensuite, les clients reçoivent à nouveau une page vierge dans nextcloud. Lorsque j'exécute la commande et ferme le terminal immédiatement, les clients y ont également accès, mais le perdent après 5 minutes. 

J'ai essayé de sauvegarder le nextcloud sql et exécuter apt-get purge --auto-remove mariadb-server. Ensuite, l’installation de MariaDB sort du didacticiel en important la sauvegarde SQL au lieu d’en créer une nouvelle. N'a pas tout changé.

L'essai suivant était update-rc.d mysql defaults et update-rc.d mysql enable. Mais après un redémarrage, il ne reste que la page vierge. L'accès n'est possible que pendant 5 minutes en commençant par le manuel d'entretien. 

J'ai aussi essayé le BUM - BootUpManager mais le service semble être activé. J'ai vu que vous pouvez également démarrer des services manuellement. Alors essayé avec mysql et surprise: nextcloud disponible pendant 5 minutes tandis que BUM raccroche: D 

J'ai trouvé mariadb.com/kb/en/mariadb/starting-and-stopping-mariadb-automatically/ aussi, mais je n'ai rien essayé, car il me semble que quelque chose d'autre ne va vraiment pas. 

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:

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>

Contenu dans /ect/init.d (si utile):

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

Malheureusement, Google ne peut pas m'aider. J'essaie d'expliquer autant que je peux, peut-être que cela vous aidera à m'aider. Merci beaucoup!

8
Lw Bi

Longue question pour rien ... Je n'ai jamais entendu parler d'AppArmor mais c'était la raison. La réponse ici l'a corrigé. Ne vous souciez pas de l'ERREUR d'apparmor, le profil n'existerait pas.

Sudo aa-status vous montre ce que fait apparmor; ce qui a réellement un politique appliquée, par rapport à ce qui est juste pour se plaindre.

Sudo apt-get install apparmor-utils ajoute quelques commandes qui font le Les profils apparmor plus faciles à gérer, tels que ...

Sudo aa-complain /usr/sbin/mysqld fait passer le profil de "appliquer" à se plaindre. (aa-force le retourne.)

Une fois que cela est fait, Sudo service apparmor reload redémarre apparmor et voila ... Sudo /etc/init.d/mysql start fonctionne, et le serveur reste en place.

4
Lw Bi

FYI:

Dans mon cas, ni la solution de Vincent ni celle de Lw Bi ne fonctionnaient exactement, j'avais besoin d'actions supplémentaires.

Désactiver le profil en plaçant un lien dans /etc/apparmor.d/disable/ n'a tout simplement pas fonctionné, je ne sais pas pourquoi.

D'autre part, configurer MySQL en mode réclamation ne fonctionnait pas non plus immédiatement.

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

Paramétrer /usr/sbin/mysqld en mode réclamation.

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

J'avais besoin d'ajouter les lignes:

/usr/sbin/mysqld {
}

à /etc/apparmor.d/usr.sbin.mysqld, puis je pourrais le configurer avec succès en mode réclamation.

6
kerzane

Déplacer mysqld vers le groupe "se plaindre" ne suffisait pas dans mon cas (MariaDB 10.1.21 fonctionnant sous Ubuntu 16.04) . Je devais complètement désactiver apparmor pour mysqld:

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

Maintenant tout fonctionne bien.

4
Vincent

Veuillez noter que depuis 10.1.10, MariaDB utilise systemd pour démarrer le service. Si vous avez essayé MYSQLD_STARTUP_TIMEOUT et que cela n'a pas fonctionné, vous utilisez probablement cette version ou une version ultérieure. Le script /etc/init.d/mysql n'est plus utilisé. MYSQLD_STARTUP_TIMEOUT n'a donc aucun effet.

Vous devez trouver votre fichier mariadb.service. Dans notre cas, il ne contenait pas de délai d'attente, de sorte que la valeur par défaut de MariaDB était utilisée. Il suffit d'ajouter:

TimeoutStartSec = 0

Dans la section [Service], et il ne sera jamais expirer.

Ce serait une bonne idée de créer votre propre fichier de configuration contenant ce fichier afin qu'il ne soit pas écrasé par les réinstallations ultérieures.

Sur Ubuntu 18.04, vous allez affiner ce fichier dans 

/lib/systemd/system/mariadb.service

Mettez votre propre fichier dans

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

N'oubliez pas de lancer systemctl daemon-reload après avoir ajouté le délai d'expiration quelque part (et vérifiez peut-être/var/log/syslog pour voir si le rechargement a réussi), sinon votre délai d'expiration sera ignoré.

2
Dave Hindle

Exécutez les commandes suivantes:

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

C'est ce qui a fonctionné pour moi:

La correction n'a pas fonctionné pour moi.

$ Sudo aa-plainte/usr/sbin/mysqld Définition de/usr/sbin/mysqld sur se plaindre en mode.

ERREUR: /etc/apparmor.d/usr.sbin.mysqld ne contient aucun profil Donc, je désactivé le profil (avec aa-disable qui semble être équivalent à la solution de plutocrat)

$ Sudo a-désactiver/usr/sbin/mysqld Désactiver/usr/sbin/mysqld. JE mysqld-akonadi et mysqld-digikam sont également désactivés.

Un rechargement d'appareil ne suffisait pas, alors j'ai dû redémarrer et mariadb commencé parfaitement bien.

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

0
Meetai.com