dpkg -S /etc/init.d/mysql
mariadb-server-10.1: /etc/init.d/mysql
Le souci c’est qu’en voulant faire une mise à jour des apps , une app en l’occurence (gitea) n’a jamais voulu se mettre à jour ! d’ou le probleme de base de donnée , et la je ne comprend pas troip d’ou cela peut venir !
Hello,
de nouveau tests, je pense qu’on se rapproche de la cause du truc …
Est-ce que tu peux faire un
ls -l /etc/systemd/system/mysql.service
Chez moi ça renvoie :
lrwxrwxrwx 1 root root 35 Jun 13 2018 /etc/systemd/system/mysql.service -> /lib/systemd/system/mariadb.service
(qui veut dire que mysql est bien un lien symbolique vers mariadb, donc bien un alias … chez toi je m’attends à ce que ce ne soit pas le cas d’après les symptomes que tu décris … pas sur de savoir pourquoi si c’est le cas, mais on peut y remédier)
Hello,
Je m’incruste encore, mais mes symptômes sont les mêmes…
La commande ls -l /etc/systemd/system/mysql.service ne me renvoie rien !
Il n’y a rien concernant Mysql ou Mariadb dedans… 
Uuuuuh tu es sur que ça ne renvoie rien ? Soit c’est censé te dire que le fichier n’existe pas, soit c’est censé renvoyer une ligne avec les infos …
Si, ça me renvoie des choses, mais rien concernant Mysql ou Mariadb :
lrwxrwxrwx 1 root root 40 oct. 20 2019 dbus-org.freedesktop.Avahi.service -> /lib/systemd/system/avahi-daemon.service
drwxr-xr-x 2 root root 4096 oct. 20 2019 default.target.wants
drwxr-xr-x 2 root root 4096 oct. 20 2019 getty.target.wants
drwxr-xr-x 2 root root 4096 mai 30 23:00 multi-user.target.wants
drwxr-xr-x 2 root root 4096 oct. 20 2019 network-online.target.wants
lrwxrwxrwx 1 root root 40 oct. 20 2019 redis.service -> /lib/systemd/system/redis-server.service
lrwxrwxrwx 1 root root 9 nov. 1 2019 samba-ad-dc.service -> /dev/null
drwxr-xr-x 2 root root 4096 mai 22 17:53 slapd.service.d
drwxr-xr-x 2 root root 4096 oct. 20 2019 sockets.target.wants
lrwxrwxrwx 1 root root 31 oct. 20 2019 sshd.service -> /lib/systemd/system/ssh.service
drwxr-xr-x 2 root root 4096 oct. 20 2019 sysinit.target.wants
lrwxrwxrwx 1 root root 35 oct. 20 2019 syslog.service -> /lib/systemd/system/rsyslog.service
drwxr-xr-x 2 root root 4096 oct. 20 2019 timers.target.wants
-rw-r--r-- 1 root root 385 mai 14 16:07 uwsgi-app@.service
-rw-r--r-- 1 root root 217 oct. 10 2019 yunoprompt.serviceAu temps pour moi, ça me renvoie :
ls: impossible d'accéder à '/etc/systemd/system/mysql.service': Aucun fichier ou dossier de ce type
Bon du coup j’en déduis que tu as tappé
ls -l /etc/systemd/system/
et non
ls -l /etc/systemd/system/mysql.service
mais que cette commande renverrait que le fichier n’existe pas … Est-ce que tu peux confirmer que c’est vraiment le même probleme que discuté ici en tapant
systemctl status mysql
et en vérifiant que le début commence par
● mysql.service - LSB: Start and stop the mysql database server daemon
Loaded: loaded (/etc/init.d/mysql; generated; vendor preset: enabled)
(notamment le /etc/init.d…)
Oui, j’ai tappé ls -l /etc/systemd/system/
et
systemctl status mysql me renvoie bien
● mysql.service - LSB: Start and stop the mysql database server daemon Loaded: loaded (/etc/init.d/mysql; generated; vendor preset: enabled) Active: active (running) since Tue 2020-06-02 09:26:02 CEST; 7h ago
Hmokay alors essayons un fix avec :
systemctl disable mysql
systemctl enable mysql
Est-ce qu’après ça,
ls -l /etc/systemd/system/mysql.service
explique bien que le fichier est un lien symbolique vers mariadb.service ?
Après désactivation et réactivation, j’ai toujours la même réponse :
ls: impossible d'accéder à '/etc/systemd/system/mysql.service': Aucun fichier ou dossier de ce type
Alors quid de
systemctl disable mysql
systemctl disable mariadb
systemctl enable mariadb
Hééé, on dirait que cette fois-ci ça fasse quelque chose !
Il m’a créé des liens symboliques à gogo :
Created symlink /etc/systemd/system/mysql.service → /lib/systemd/system/mariadb.service. Created symlink /etc/systemd/system/mysqld.service → /lib/systemd/system/mariadb.service. Created symlink /etc/systemd/system/multi-user.target.wants/mariadb.service → /lib/systemd/system/mariadb.service.
et du coup, ls -l /etc/systemd/system/mysql.service me donne :
lrwxrwxrwx 1 root root 35 juin 2 16:48 /etc/systemd/system/mysql.service -> /lib/systemd/system/mariadb.service
Et dans le webmin de yunohost, mysql est en cours d’exécution ! (depuis 7 heures !)
Un grand merci !
1 Like
Du coup je vais essayer de mettre un fix dans le code pour que ce soit automagiquement géré … est-ce que vous pouvez juste préciser si votre serveur est relativement récent (quelques semaines / mois) ou bien date de plusieurs années ?
@Aleks
Mon serveur a 10 mois.
Mon server à 18 mois.
Bonjour,
Mon serveur avait le même problème.
Grâce à vos messages, mysql a redémarré.
@Aleks, mon serveur a presque 1 an.
1 Like
Pour les gens qui tombent sur ce fil de discussion: le problème est normalement réglé en mettant à jour vers la dernière version (3.8.4.7)
For people stumbling on this thread, the issue should be fixed by upgrading to the latest version (3.8.4.7)
Merci @Aleks 
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.