Bonjour,
J’ai une Brique qui fonctionnait bien depuis plus d’un an maintenant. C’est une LIME2.
J’ai quelques problèmes depuis deux jours, je vous mets l’historique et ce que j’ai ci-dessous :
Problème initial :
a. Après une sauvegarde en ligne de commande (sudo yunohost backup create
), la Brique ne répond plus (interface web ne charge pas et terminal reste « en attente » ; en tentant de me connecter en ssh avec la commande ssh -v root@mabrique
, il bloquait sur quelque chose comme « waiting for reply » indéfiniment).
b. Après un redémarrage forcé, l’interface web ne reconnaissait pas mon utilisateur, via ssh, il n’était possible de me connecter qu’en root ; il ne trouvait pas l’utilisateur admin et le précisait régulièrement lors de commande (moulinette).
Ce problème ne s’est pas reproduit depuis.
c. Après un redémarrage (reboot
via session root en ssh), elle fonctionne « normalement », je peux me connecter via mon utilisateur normal, l’interface web marche, je peux me connecter en ssh en root et en admin, mais, depuis :
Symptômes récurrents :
- Après un moment (10 minutes, 10 heures…), MySQL plante (erreur 111).
- Si j’efface un fichier sur NextCloud, après un redémarrage de la Brique, il revient, pareil pour les notes (donc les modifications sont effacées !)…
- TTRSS mets les flux à jour, mais ne retiens pas les modifications ; après un redémarrage, les mises à jour ont disparu.
- L’historique bash de mes sessions ssh n’est pas enregistré.
MySQL
Quand MySQL plante, systemctl status mysql.service
donne :
● mysql.service - LSB: Start and stop the mysql database server daemon
Loaded: loaded (/etc/init.d/mysql)
Active: active (exited) since ven. 2018-04-27 11:40:20 CEST; 47min ago
Process: 803 ExecStart=/etc/init.d/mysql start (code=exited, status=0/SUCCESS)
Mais, si je fais systemctl restart mysql
, j’ai :
Job for mysql.service failed. See 'systemctl status mysql.service' and 'journalctl -xn' for details.
systemctl status mysql.service
donne alors :
● mysql.service - LSB: Start and stop the mysql database server daemon
Loaded: loaded (/etc/init.d/mysql)
Active: failed (Result: exit-code) since ven. 2018-04-27 12:31:05 CEST; 1min 27s ago
Process: 7454 ExecStop=/etc/init.d/mysql stop (code=exited, status=0/SUCCESS)
Process: 7479 ExecStart=/etc/init.d/mysql start (code=exited, status=1/FAILURE)
avril 27 12:31:05 mondomaine.tld mysql[7479]: Starting MariaDB database server: mysqld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . failed!
avril 27 12:31:05 mondomaine.tld systemd[1]: mysql.service: control process exited, code=exited status=1
avril 27 12:31:05 mondomaine.tld systemd[1]: Failed to start LSB: Start and stop the mysql database server daemon.
avril 27 12:31:05 mondomaine.tld systemd[1]: Unit mysql.service entered failed state.
Et, pour journalctl -xn
:
-- Logs begin at ven. 2018-04-27 11:39:33 CEST, end at ven. 2018-04-27 12:40:06 CEST. --
avril 27 12:40:06 mondomaine.tld rngd[608]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
avril 27 12:40:06 mondomaine.tld /etc/init.d/mysql[9224]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in
avril 27 12:40:06 mondomaine.tld /etc/init.d/mysql[9224]: [61B blob data]
avril 27 12:40:06 mondomaine.tld /etc/init.d/mysql[9224]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111 "Connection refused")'
avril 27 12:40:06 mondomaine.tld /etc/init.d/mysql[9224]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
avril 27 12:40:06 mondomaine.tld /etc/init.d/mysql[9224]:
avril 27 12:40:06 mondomaine.tld mysql[8706]: Starting MariaDB database server: mysqld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . failed!
avril 27 12:40:06 mondomaine.tld systemd[1]: mysql.service: control process exited, code=exited status=1
avril 27 12:40:06 mondomaine.tld systemd[1]: Failed to start LSB: Start and stop the mysql database server daemon.
-- Subject: L'unité (unit) mysql.service a échoué
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- L'unité (unit) mysql.service a échoué, avec le résultat failed.
avril 27 12:40:06 mondomaine.tld systemd[1]: Unit mysql.service entered failed state.
(C’est moi qui remplace “mondomaine.tld”.)
Après chaque redémarrage, tout fonctionne, inclus phpMyAdmin (j’avais installé l’app il y a un moment). J’ai pu exporter les bases de données par là (pour test et au cas où).
Diagnostic
Voilà le contenu de Yunohost > Administration > Outils > Diagnostic :
{
"host": "Debian 8.10",
"kernel": "3.16.0-5-armmp",
"packages": {
"yunohost": {
"repo": "local",
"version": "2.7.9"
},
"yunohost-admin": {
"repo": "stable",
"version": "2.7.7"
},
"moulinette": {
"repo": "stable",
"version": "2.7.7"
},
"ssowat": {
"repo": "stable",
"version": "2.7.7"
}
},
"backports": [
"php-net-ldap3"
],
"system": {
"disks": {
"mmcblk0p1": "Mounted on /, 58.6GiB (11.0GiB free)"
},
"memory": {
"ram": "1005.4MiB (607.7MiB free)",
"swap": "0B (0B free)"
}
},
"nginx": [
"nginx: the configuration file /etc/nginx/nginx.conf syntax is ok",
"nginx: configuration file /etc/nginx/nginx.conf test is successful"
],
"services": {
"etherpad_mypads": "running (not-found)",
"ynh-hotspot": "inactive (not-found)",
"nsswitch": "inactive (not-found)",
"fail2ban": "running (enabled)",
"yunohost-api": "running (enabled)",
"mysql": "running (enabled)",
"glances": "running (enabled)",
"rspamd": "running (enabled)",
"rmilter": "running (enabled)",
"avahi-daemon": "running (enabled)",
"dovecot": "running (enabled)",
"php5-fpm": "running (enabled)",
"uwsgi": "running (enabled)",
"nslcd": "running (enabled)",
"ynh-vpnclient": "running (not-found)",
"nginx": "running (enabled)",
"ssh": "running (enabled)",
"redis-server": "running (enabled)",
"metronome": "running (enabled)",
"postfix": "running (enabled)",
"yunohost-firewall": "running (disabled)",
"dnsmasq": "running (enabled)",
"slapd": "running (enabled)"
},
"applications": {
"etherpad_mypads": "Etherpad Mypads",
"wallabag2": "Wallabag",
"phpmyadmin": "phpMyAdmin",
"hotspot": "Wifi Hotspot",
"ttrss": "Tiny Tiny RSS",
"vpnclient": "VPN Client",
"neutrinet": "Neutrinet",
"roundcube": "Roundcube",
"doctorcube": "Doctor Cube",
"nextcloud": "Nextcloud"
},
"security": {
"CVE-2017-5754": {
"name": "meltdown",
"vulnerable": false
}
}
}
Carte SD
J’ai éteint ma Brique, sorti la carte SD pour la mettre dans mon ordinateur.
Je l’ai clonée, j’ai vérifié qu’elle n’est pas en lecture seule (via sudo hdparm /dev/mmcblk0
; l’écriture est bien permise) et j’ai fait sudo fsck.ext4 /dev/mmcblk0p1
qui donne :
e2fsck 1.43.5 (04-Aug-2017)
/dev/mmcblk0p1 : récupération du journal
le drapeau needs_recovery n'est pas activé, mais le journal contient des données.
Exécuter quand même le journal<o>? oui
fsck.ext4: Unknown code ____ 251 lors de la récupération du journal de /dev/mmcblk0p1
fsck.ext4: impossible d'initialiser les drapeaux du superbloc sur /dev/mmcblk0p1
/dev/mmcblk0p1 : **ATTENTION : le système de fichiers contient encore des erreurs**
Ce qui ressemble au problème d’une autre Brique ici et soulève la même question : existe-t-il un moyen de vérifier l’intégrité d’une carte SD ? Cette erreur implique-t-elle que la carte est physiquement foutue ?
Mais, du coup, j’aimerais aussi pouvoir assez vite retrouver une Brique fonctionnelle, est-ce que le diagnostic d’une carte SD corrompue se confirme ou dois-je suivre une autre piste ?