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 ?
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)
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.