# Erreur MariaDB

**URL:** <https://www.debian-fr.org/t/erreur-mariadb/88866>\
**Category:** Support Debian\
**Created:** [Septembre 26, 2023, 2:28 UTC](https://www.debian-fr.org/t/erreur-mariadb/88866 "2023-09-26T14:28:00Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![epoc](https://www.debian-fr.org/user_avatar/www.debian-fr.org/epoc/32/12060_2.png) [@epoc](https://www.debian-fr.org/u/epoc)\
**Post date:** [Septembre 26, 2023, 2:28 UTC](https://www.debian-fr.org/t/erreur-mariadb/88866/1 "2023-09-26T14:28:00Z")

</div>

Bonjour,

Mon système: Linux Debian 11.7  
mysql Ver 15.1 Distrib 10.5.19-MariaDB  
Serveur Apache/2.4.56

J’ai une erreur subite durant l’utilisation de GLPI sur mon serveur:  
_Un lien vers le serveur SQL n’a pas pu être établi. Veuillez vérifier votre configuration._  
_Le serveur Mysql est inaccessible. Vérifiez votre configuration._

J’ai constaté l’erreur ci-dessous sur Mariadb:

```nohighlight
systemctl status mysql.service
● mariadb.service - MariaDB 10.5.19 database server
    Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
    Active: failed (Result: exit-code) since Tue 2023-09-26 11:56:42 CEST; 1h 9min ago
      Docs: man:mariadbd(8)
            https://mariadb.com/kb/en/library/systemd/
  Main PID: 532 (code=exited, status=1/FAILURE)
    Status: "MariaDB server is down"
       CPU: 211ms

sept. 26 11:56:41 debian11ocs mariadbd[532]: 2023-09-26 11:56:41 0 [Note] InnoDB: Starting shutdown...
sept. 26 11:56:42 debian11ocs mariadbd[532]: 2023-09-26 11:56:42 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
sept. 26 11:56:42 debian11ocs mariadbd[532]: 2023-09-26 11:56:42 0 [ERROR] Plugin 'InnoDB' init function returned error.
sept. 26 11:56:42 debian11ocs mariadbd[532]: 2023-09-26 11:56:42 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
sept. 26 11:56:42 debian11ocs mariadbd[532]: 2023-09-26 11:56:42 0 [Note] Plugin 'FEEDBACK' is disabled.
sept. 26 11:56:42 debian11ocs mariadbd[532]: 2023-09-26 11:56:42 0 [ERROR] Unknown/unsupported storage engine: InnoDB
sept. 26 11:56:42 debian11ocs mariadbd[532]: 2023-09-26 11:56:42 0 [ERROR] Aborting
sept. 26 11:56:42 debian11ocs systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
sept. 26 11:56:42 debian11ocs systemd[1]: mariadb.service: Failed with result 'exit-code'.
sept. 26 11:56:42 debian11ocs systemd[1]: Failed to start MariaDB 10.5.19 database server.

```

En voulant démarrer Mariadb, j’ai le message ci-dessous:

```nohighlight
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/run/mysqld/mysqld.so

```

Je suppose que le système n’a plus assez de place pour lancer les processus…  
Ci-dessous les volumes utilisés:

```nohighlight
df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev 3,9G 0 3,9G 0% /dev
tmpfs 788M 764K 787M 1% /run
/dev/sda1 23G 5,5G 17G 26% /
tmpfs 3,9G 0 3,9G 0% /dev/shm
tmpfs 5,0M 0 5,0M 0% /run/lock
/dev/sda7 1,8G 52K 1,7G 1% /tmp
/dev/sda5 9,1G 8,6G 3,3M 100% /var
/dev/sda8 423G 80K 401G 1% /home
tmpfs 788M 0 788M 0% /run/user/1000

```

Si c’est le cas, que faut-il supprimer pour récupérer de l’espace libre… Sans KC le système…  
si autre chose, merci de m’indiquer ou chercher…

Merci d’avance

---

<div class="post-metadata">

**Author:** ![loicmtp](https://www.debian-fr.org/user_avatar/www.debian-fr.org/loicmtp/32/13315_2.png) [@loicmtp](https://www.debian-fr.org/u/loicmtp)\
**Post date:** [Septembre 26, 2023, 2:53 UTC](https://www.debian-fr.org/t/erreur-mariadb/88866/2 "2023-09-26T14:53:50Z")

</div>

Bonjour

D’apres ce que je vois c’est que le probleme peut venir du répertoire/partition /var .

Que vous disent les logs?

ps: [error 2002](https://dev.mysql.com/doc/refman/8.0/en/can-not-connect-to-server.html)

---

<div class="post-metadata">

**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\
**Post date:** [Septembre 26, 2023, 3:15 UTC](https://www.debian-fr.org/t/erreur-mariadb/88866/3 "2023-09-26T15:15:57Z")

</div>

c’est effectivement un problème d’espace dans la partition /var contenant /var/lib/mysql.

Il faut soit faire de la place, soit au vue du partitionnement revoir l’installation ou dans un premier temps recréer une partition sur laquelle vous monterez le point de montage /var/lib/mysql (pensez à déplacer les données dessus avant de le monter en lieu et place.

---

<div class="post-metadata">

**Author:** ![epoc](https://www.debian-fr.org/user_avatar/www.debian-fr.org/epoc/32/12060_2.png) [@epoc](https://www.debian-fr.org/u/epoc)\
**Post date:** [Septembre 27, 2023, 8:01 UTC](https://www.debian-fr.org/t/erreur-mariadb/88866/4 "2023-09-27T08:01:10Z")

</div>

Bonjour Clochette,

oui, j’ai vu cela, en attendant un retour, j’ai supprimer une ancienne sauvegarde de GLPI, et j’ai récupérer un peut d’espace, de ce fait les processus ont été lancées…  
mon serveur est reparti…

Ma question:  
Est-il possible, si je mets le DD de mon linux en esclave sur un autre système, et que je boot via un PQ Magic, ou un Gparted, afin de redimensionner les partissions, cela risque d’avoir un impact négatif sur mon système…? en provoquant une instabilité…? voir rendre le serveur inutilisable…?

Merci d’avance…

---

<div class="post-metadata">

**Author:** ![epoc](https://www.debian-fr.org/user_avatar/www.debian-fr.org/epoc/32/12060_2.png) [@epoc](https://www.debian-fr.org/u/epoc)\
**Post date:** [Septembre 27, 2023, 8:03 UTC](https://www.debian-fr.org/t/erreur-mariadb/88866/5 "2023-09-27T08:03:05Z")

</div>

Bonjour Loicmtp,

Oui, c’est bien le répertoire …/var/… qui pose problème…  
Comment récupérer les logs, si tu peux me laisser la commande…

Merci d’avance…

---

<div class="post-metadata">

**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\
**Post date:** [Septembre 27, 2023, 8:09 UTC](https://www.debian-fr.org/t/erreur-mariadb/88866/6 "2023-09-27T08:09:56Z")

</div>

> [@epoc](#):
>
> Est-il possible, si je mets le DD de mon linux en esclave sur un autre système, et que je boot via un PQ Magic, ou un Gparted, afin de redimensionner les partissions, cela risque d’avoir un impact négatif sur mon système…?

C’est possible de faire ainsi, mais je recommande pas de déplacer les partitions de cette manière sans sauvegarde.  
Maintenant ce que j’entend par revoir l’installation s’est de s’appuyer sur du LVM pour la partie partitionnement et pourquoi pas de séparer un poil plus certaines partie du système.  
J’aurai bien vu un volume logique pour /var, ainsi que deux autres pour isolé /var/lib/mysql et /var/log.

surtout que pour un serveur (si s’en ai bien un une partition /home de plus de 400G c’est … 🤨

---

<div class="post-metadata">

**Author:** ![epoc](https://www.debian-fr.org/user_avatar/www.debian-fr.org/epoc/32/12060_2.png) [@epoc](https://www.debian-fr.org/u/epoc)\
**Post date:** [Septembre 27, 2023, 8:13 UTC](https://www.debian-fr.org/t/erreur-mariadb/88866/7 "2023-09-27T08:13:40Z")

</div>

Les logs:

```nohighlight
 ls -lrt /var/log
total 612
drwxrwxrwx 3 root root 4096 13 juin 2022 installer
drwxr-sr-x+ 3 root systemd-journal 4096 13 juin 2022 journal
drwx------ 2 root root 4096 13 juin 2022 private
drwxrwxrwx 3 root root 4096 14 juin 2022 runit
drwxr-s--- 2 mysql adm 4096 16 juin 2022 mysql
drwxrwxrwx 2 root root 4096 19 juin 2022 proftpd
drwxrwxr-x 2 www-data www-data 4096 20 juin 2022 ocsinventory-server
drwxrwxrwx 2 root adm 4096 11 juil. 2022 apache2
drwxrwxrwx 2 root root 4096 26 sept. 12:26 apt
-rw-r----- 1 root adm 81136 26 sept. 17:03 kern.log
-rw-r----- 1 root adm 6289 26 sept. 17:03 debug.1
-rw-rw---- 1 root utmp 384 26 sept. 17:03 btmp
-rw-r----- 1 root adm 0 27 sept. 00:00 debug
-rw-r----- 1 root adm 74727 27 sept. 00:10 messages
-rw-r----- 1 root adm 236940 27 sept. 10:05 syslog
-rw-r----- 1 root adm 147750 27 sept. 10:05 daemon.log
-rw-rw-r-- 1 root utmp 2688 27 sept. 10:05 wtmp
-rw-rw-r-- 1 root utmp 292292 27 sept. 10:05 lastlog
-rw-r----- 1 root adm 12969 27 sept. 10:05 auth.log

```

---

<div class="post-metadata">

**Author:** ![epoc](https://www.debian-fr.org/user_avatar/www.debian-fr.org/epoc/32/12060_2.png) [@epoc](https://www.debian-fr.org/u/epoc)\
**Post date:** [Septembre 27, 2023, 8:38 UTC](https://www.debian-fr.org/t/erreur-mariadb/88866/8 "2023-09-27T08:38:38Z")

</div>

Merci du retour…  
En fait, j’ai suivi le système de partition logique de Linux…  
Je n’ai pas été assez vigilent la dessus… 🤔

Je vais essayer de porter une attention quotidienne sur la chose… 🤨

Encore Merci…

---

<div class="post-metadata">

**Author:** ![loicmtp](https://www.debian-fr.org/user_avatar/www.debian-fr.org/loicmtp/32/13315_2.png) [@loicmtp](https://www.debian-fr.org/u/loicmtp)\
**Post date:** [Septembre 27, 2023, 8:46 UTC](https://www.debian-fr.org/t/erreur-mariadb/88866/9 "2023-09-27T08:46:16Z")

</div>

Hello  
Installez ncdu et regardez les gros volumes dans le repertoire /var concerné. Ensuite instaurez un logrotate drastique ou faites des «&nbsp;[truncate](https://linux.die.net/man/1/truncate)&nbsp;» sur les fichiers (edit: de log bien sur) les plus gros

Peut etre serait ce suffisant pour que mysql puisse se relancer

Ou alors:

Si vous avez de la place et que vous utilisez LVM (regardez lsblk) vous pouvez faire soit un redimensionnement soit un déport d’un répertoire vers une autre partition

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Septembre 27, 2023, 9:07 UTC](https://www.debian-fr.org/t/erreur-mariadb/88866/10 "2023-09-27T09:07:12Z")

</div>

9G c’est trop petit pour un /var.  
Les logs c’est minima 3 à 4G dans une configuration serveur pour être certain de ne pas être impacté avec une bonne gestion des rotations.  
Sachant que la base de données est dans `/var/lib/mysq`l il faut avoir une estimation du volume de données pour le dimensionner et en faire une partition spécifique.  
La place utilisée par /home est abherante, et une partie devrait être utilisée par les autres besoins.  
LVM est à utiliser, il peut y avoir un volume group par disque ou grouper les deux disque dans un seul (mais plus risqué en cas de dégât sur un disque).

---

<div class="post-metadata">

**Author:** ![epoc](https://www.debian-fr.org/user_avatar/www.debian-fr.org/epoc/32/12060_2.png) [@epoc](https://www.debian-fr.org/u/epoc)\
**Post date:** [Septembre 27, 2023, 9:14 UTC](https://www.debian-fr.org/t/erreur-mariadb/88866/11 "2023-09-27T09:14:59Z")

</div>

Ho… du travail en perspective… 🤔  
je vais cloner mon DD, et travailler sur le clone afin de ne pas impacter le serveur… 😉

Merci pour le retour…

---

<div class="post-metadata">

**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\
**Post date:** [Septembre 27, 2023, 9:54 UTC](https://www.debian-fr.org/t/erreur-mariadb/88866/12 "2023-09-27T09:54:29Z")

</div>

> [@epoc](#):
>
> je vais cloner mon DD, et travailler sur le clone afin de ne pas impacter le serveur…

Je maintient le plus simple serait de travailler sur un déploiement neuf et le rapatriement des données dessus, qualification et finalement mise en production du nouveau serveur.  
Cela te permettra d’être à jour, de maîtriser ton partitionnement, et pourquoi pas revoir et optimiser le système et les applicatifs.

En attendant réduit le /home sur ton serveur (d’abord le système de fichier, puis la partition) et profit-en pour recréer une partition avec un système de fichier propre de 15Go , monte la sur /tmp et copie l’intégralité des données dans /var.  
Une fois fait tu peux envisager de démonter la partition /var et la remplacer (création d’un point de montage dans le fichier fstab) par la nouvelle partition /var.

---

<div class="post-metadata">

**Author:** ![loicmtp](https://www.debian-fr.org/user_avatar/www.debian-fr.org/loicmtp/32/13315_2.png) [@loicmtp](https://www.debian-fr.org/u/loicmtp)\
**Post date:** [Septembre 27, 2023, 1:28 UTC](https://www.debian-fr.org/t/erreur-mariadb/88866/13 "2023-09-27T13:28:25Z")

</div>

> [@Clochette](#):
>
> Je maintient le plus simple serait de travailler sur un déploiement neuf et le rapatriement des données dessus, qualification et finalement mise en production du nouveau serveur.

C’est sûr mais en meme temps des manipulations sur un serveur peuvent etre instructives

---

<div class="post-metadata">

**Author:** ![epoc](https://www.debian-fr.org/user_avatar/www.debian-fr.org/epoc/32/12060_2.png) [@epoc](https://www.debian-fr.org/u/epoc)\
**Post date:** [Septembre 27, 2023, 2:09 UTC](https://www.debian-fr.org/t/erreur-mariadb/88866/14 "2023-09-27T14:09:14Z")

</div>

Bonjour,

pour le retour merci…  
j’ai du pain sur la planche…  
je vais travailler la chose…

encore merci

---

<div class="post-metadata">

**Author:** ![dindoun](https://www.debian-fr.org/user_avatar/www.debian-fr.org/dindoun/32/4281_2.png) [@dindoun](https://www.debian-fr.org/u/dindoun)\
**Post date:** [Septembre 27, 2023, 6:22 UTC](https://www.debian-fr.org/t/erreur-mariadb/88866/15 "2023-09-27T18:22:56Z")

</div>

> [@epoc](#):
>
> `2002`

salut  
tu peux tenter ça :  
[https://brunosanchiz.fr/spip.php?article477](https://brunosanchiz.fr/spip.php?article477)  
`rm /var/lib/mysql/ib_logfile*`  
Evidemment pour plus de sureté tu peux toujours les copier plutot que les effacer, mais ça a marché chez moi

---

<div class="post-metadata">

**Author:** ![dindoun](https://www.debian-fr.org/user_avatar/www.debian-fr.org/dindoun/32/4281_2.png) [@dindoun](https://www.debian-fr.org/u/dindoun)\
**Post date:** [Septembre 27, 2023, 7:24 UTC](https://www.debian-fr.org/t/erreur-mariadb/88866/16 "2023-09-27T19:24:51Z")

</div>

> [@epoc](#):
>
> `ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/run/mysqld/mysqld.so`

pour cette ligne , il y a parfois une ereur de configuration entre  
unix\_socket ( ou auth\_socket ) et mysql\_native\_password

[https://brunosanchiz.fr/spip.php?article319](https://brunosanchiz.fr/spip.php?article319)

donnes nous le résultat de

` egrep "port =|socket =" /etc/mysql/my.cnf`

---

<div class="post-metadata">

**Author:** ![loicmtp](https://www.debian-fr.org/user_avatar/www.debian-fr.org/loicmtp/32/13315_2.png) [@loicmtp](https://www.debian-fr.org/u/loicmtp)\
**Post date:** [Septembre 28, 2023, 3:26 UTC](https://www.debian-fr.org/t/erreur-mariadb/88866/17 "2023-09-28T03:26:02Z")

</div>

> [@dindoun](#):
>
> Evidemment pour plus de sureté tu peux toujours les copier plutot que les effacer, mais ça a marché chez moi

L’avantage de truncate c’est que n’efface que le contenu en MO, GO que vous lui demandez d’effacer et laisse le fichier

---

<div class="post-metadata">

**Author:** ![epoc](https://www.debian-fr.org/user_avatar/www.debian-fr.org/epoc/32/12060_2.png) [@epoc](https://www.debian-fr.org/u/epoc)\
**Post date:** [Septembre 28, 2023, 7:49 UTC](https://www.debian-fr.org/t/erreur-mariadb/88866/18 "2023-09-28T07:49:15Z")

</div>

> [@dindoun](#):
>
> rm /var/lib/mysql/ib\_logfile\*

Bonjour,

j’ai appliqué, et j’ai récupérer quelques Mo..  
merci, je garde la commande..

👊 👍

---

<div class="post-metadata">

**Author:** ![epoc](https://www.debian-fr.org/user_avatar/www.debian-fr.org/epoc/32/12060_2.png) [@epoc](https://www.debian-fr.org/u/epoc)\
**Post date:** [Septembre 28, 2023, 8:04 UTC](https://www.debian-fr.org/t/erreur-mariadb/88866/19 "2023-09-28T08:04:10Z")

</div>

Bonjour,

Merci du retour…  
Je vais refaire un serveur sur une nouvelle machine…en prenant en compte tout ce qui à été dit…

Juste pour donner des infos sur mon univers de travail:  
Je m’occupe d’un parc de 300 PC (Fixes, portables) globalement…  
Et au moment de changer la machine d’un utilisateur, soit pour désastre, ou obsolescence OS, je récupère le PC (qui est encore très fiable), je le gonfle en RAM, je le nettoie correctement, je lui mets un DD, et je lui donne une seconde vie comme serveur Linux…  
De ce fait, je patiente juste pour une occasion de récupérer une machine, et me mettre dessus…  
Cela me prendra un certain temps…  
J’installe dessus le couple GLPI/OCS, et le tour est joué, avec les même paramètres réseau NetBIOS, IP afin que les agents déjà déployés soient tous fonctionnels, et au bout de 3/4 jours, la base de données est reconstituée…

…/…

Et voila…  
Pour l’heur, je me ferai la min sur un VM pour gérer le partitionnement Linux…  
Merci à tous, je vous tiendrai informé…
