Unable to start service 'mysql'

Mon serveur YunoHost

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.

Merci.

Edit : tout ce que j’ai comme messages d’erreurs c’est ce qui apparait dans l’interface web :
https://arnauld.org/zerobin/?f977875727458282#1wu7MWqMzPBTgRV92HL1E84jZlbs4f77nbwn9EiFLos=

Pour le log

journalctl -u mariadb

Vérifie que tu as de l’espace disque

df -h

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).

Bonjour,

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.

ppr

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.

J’ai bien beaucoup d’espace disque (un hdd sur lequel est mis yunohost) :

Filesystem Size Used Avail Use% Mounted on
/dev/root 30G 12G 17G 42% /
devtmpfs 459M 0 459M 0% /dev
tmpfs 464M 80K 463M 1% /dev/shm
tmpfs 464M 47M 417M 11% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 464M 0 464M 0% /sys/fs/cgroup
/dev/mmcblk0p1 44M 23M 21M 52% /boot
/dev/sda 287G 87G 186G 32% /media/storage
tmpfs 93M 0 93M 0% /run/user/1007

Pour le log, je l’ai mis ici :

https://arnauld.org/zerobin…

Pour les mails je parlais de l’interface roundcube, j’y ai effectivement accès comme tu l’as rectifié. Je viens d’essayer avec Thunderbird.

J’ai des sauvegardes de Nextcloud (une sauvegarde pre-upgrade du 26 janvier).

Merci.

Je confirme les coupures électriques

J’ai eu une coupure en fin de matinée juste après avoir redémarré Yunohost.

C’est bizarre y a pas d’erreur flagrante ça dit juste killed, comme si y avait un problème de mémoire ram.

Est-ce que nextcloud fonctionne au départ puis tout à coup plus ? Ça pourrais être un fichier de swap qui n’est pas remonté après le redémarrage.

La piste de la coupure est la plus crédible tout de même.

Il y aussi un log là:

tail /var/lib/mysql/TONDOMAINE.err

Il y aussi un log là:

tail /var/lib/mysql/TONDOMAINE.err

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

Est-ce que nextcloud fonctionne au départ puis tout à coup plus ?

C’est après le re-démarrage que ça ne fonctionne plus (nextcloud, mysql), avant (hier soir) ça marchait très bien.

tail -n200 /var/lib/mysql/TONDOMAINE.err | yunopaste

sudo tail -n200 /var/lib/mysql/arnauld.org.err | yunopaste
Invalid usage: No input is provided.

Usage: /usr/bin/yunopaste [OPTION]…

Read from input stream and paste the data to the YunoHost
Haste server.

For example, to paste the output of the YunoHost diagnosis, you
can simply execute the following:
yunohost tools diagnosis | /usr/bin/yunopaste

It will return the URL where you can access the pasted data.

Options:
-h, --help show this help message and exit

Je viens de re-démarrer mon Yunohost et tout semble être rentré dans l’ordre. Mysql est démarré, mon Nextcloud est en ligne, Roundcube marche…

J’attends de voir un peu au cas où quelque chose casse avant de mettre en résolu.

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.

Bon, ce matin j’ai de nouveau en rade Nextcloud et Roundcube…et mysql.

Quoi faire ?

Merci.

Pas de saturation au niveau de la RAM ou de la SWAP ?

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.

Ce qui n’est pas bon…

Et pour la ram/swap ça me parait bon :

admin@arnauld:~ $ free -m
              total        used        free      shared  buff/cache   available
Mem:            926         331          99          39         495         493
Swap:           499          14         485

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.

1 Like

dbus gère les échanges entre processus, il peut planter quand certains sont en rade donc à mon avis c’est un symptôme mais pas une cause.

1 Like

Bonjour,

Il est possible sur une Raspberry Pi d’augmenter la taille du fichier servant au swap :

ppr

1 Like