Matériel: Raspberry Pi à la maison / Brique Internet avec VPN Version de YunoHost: Dernière version J’ai accès à mon serveur : En SSH | Par la webadmin Êtes-vous dans un contexte particulier ou avez-vous effectué des modifiiations particulières sur votre instance ? : oui Si oui, expliquer: Boot sur la SD et le reste sur un hdd
Description du problème
Nextcloud, mes mails sont en rade suite à un redémarrage de mon Yunohost.
Impossible de démarrer mysql.
Je n’arrive pas à trouver les logs. Quand je vais dans /var/log/mysql les logs d’erreur sont vides.
Les 2 principales causes de mysql cassé c’est l’espace disque et les coupures électrique pendant une opération d’écriture sur la base de donnée. Enfin c’est ce qui ressort de ce forum de support.
As-tu des sauvegardes de nextcloud ?
Je ne comprends pas pourquoi tes mails sont en rade. Tu veux dire que ton webmail ne fonctionne plus ? Parce que tu peux toujours y accéder avec un client lourd je pense (sur smartphone ou sur pc thunderbird).
Je confirme les coupures électriques et les variations de tension que les Raspberry Pi n’aiment pas et particulièrement lorsqu’il y a des bases de données.
J’en ai fait l’expérience avec réinstallation complète car impossible de réparer la base de données.
L’idéal avec une Raspberry Pi est d’avoir un onduleur équipé de batteries pour palier aux coupures de courant en plus de réguler la tension.
De plus, une sauvegarde de la carte avec dd, à défaut de pouvoir restaurer les données récentes, permet de restaurer sans avoir à réinstaller.
C’est pourquoi, en dehors du fait que mon FAI n’est pas des plus adapté à l’auto-hébergement (problème avec l’envoi de courriel bloqué via zen.spamhaus.org a priori à sa demande) je suis passé sur un VPS.
Pour rassurer bien souvent seul la bdd interne de mysql est cassé pas celles de nextcloud, et ça ça se répare, il y a plein de topic qui en parle sur ce forum.
sudo tail /var/lib/mysql/arnauld.org.err
68Hope that’s ok; if not, decrease some variables in the equation.
80Thread pointer: 0x0
02Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong…
6eae80026eab200040001a80026eaf80026estack_bottom = 0x0 thread_stack 0x20000
acThe manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
20004800200301 13:00:46 mysqld_safe mysqld from pid file /var/lib/mysql/arnauld.org.pid ended
Bon, maintenant que mysql est up et Nextcloud et Roundcube sont ok je ne peux plus accéder à “services” dans l’interface web admin de Yunohost. Si je clique sur “users”, “domains”, “applications”, “syst update” ou “backup”, j’accèdes aux bonnes pages mais quand je clique sur “services” rien ne se passe…
Edit : pareil pour “monitoring” ou “diagnosis” dans la rubrique “Tools”, rien ne se passe quand je clique dessus.
Pas de saturation au niveau de la RAM ou de la SWAP ?
Je ne sais pas. Comme je n’arrive plus à voir via l’interface web les services en marche de Yunohost, j’ai tenté en ligne de commande et cela m’a donné ça :
sudo yunohost service status
Traceback (most recent call last):
File "/usr/bin/yunohost", line 214, in <module>
timeout=opts.timeout,
File "/usr/lib/python2.7/dist-packages/moulinette/__init__.py", line 136, in cli
moulinette.run(args, output_as=output_as, password=password, timeout=timeout)
File "/usr/lib/python2.7/dist-packages/moulinette/interfaces/cli.py", line 425, in run
ret = self.actionsmap.process(args, timeout=timeout)
File "/usr/lib/python2.7/dist-packages/moulinette/actionsmap.py", line 523, in process
return func(**arguments)
File "/usr/lib/moulinette/yunohost/service.py", line 287, in service_status
status = _get_service_information_from_systemd(name)
File "/usr/lib/moulinette/yunohost/service.py", line 348, in _get_service_information_from_systemd
systemd = d.get_object('org.freedesktop.systemd1', '/org/freedesktop/systemd1')
File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 241, in get_object
follow_name_owner_changes=follow_name_owner_changes)
File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 248, in __init__
self._named_service = conn.activate_name_owner(bus_name)
File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 180, in activate_name_owner
self.start_service_by_name(bus_name)
File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 278, in start_service_by_name
'su', (bus_name, flags)))
File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Désolé je ne vais pas pouvoir aider. Ça ressemble énormément aux problèmes que j’ai actuellement sur mon serveur (webadmin qui déconne, bdd qui saute) et je n’ai pas encore trouvé la cause. Je reviendrai ici si jamais j’ai du mieux. Jusqu’à présent, je ne fais que des redémarrages pour régler temporairement les problèmes.
Côté RAM et SWAP, ça me semble ok. Faudrait voir sur des pics de conso mais ça n’a pas l’air bloquant.