Bonsoir !
On a enfin réussi à débugger le problème grâce aux gens du Matrix de YunoHost (merci @otm33 particulièrement !!). J’ai attendu quelques jours de voir si je rencontrais de nouveau le problème avant de faire un retour.
J’ai donc activé les logs de dnsmasq en ajoutant dans le fichier /etc/dnsmasq.conf :
log-queries
log-facility=/var/log/dnsmasq.log
Note pour celles et ceux qui rencontrent mon souci que le fichier devient très gros très vite. Vous pouvez le purger de temps en temps avec :
truncate -s 0 /var/log/dnsmasq.log
Et virer les logs après avoir fini.
Pour ouvrir le fichier de logs et l’examiner :
sudo nano /var/log/dnsmasq.log
Et Ctrl+Fin pour aller tout à la fin du fichier.
Ça m’a permis de découvrir que l’origine du problème était la fédération Matrix : dans les deux dernières secondes qui précédaient le crash de dnsmasq, mon serveur recevait plusieurs centaines de requêtes simultanées venant de toute la fédération Matrix, et dnsmasq n’était pas configuré pour traiter tout ça. J’ai donc appliqué le fix proposé ici : Consider increasing default federation timeout · Issue #8338 · matrix-org/synapse · GitHub
Dans le fichier /etc/dnsmasq.conf, après dns-forward-max= , remplacer 150 par 300, perso j’ai mis 500.
Après cache-size=, mettre 4096.
Redémarrer dnsmasq puis redémarrer le service Matrix (Conduit dans mon cas). Puis… eh bien, attendre.
Ça m’était déjà arrivé de devoir redémarrer dnsmasq par le passé mais jamais avec une telle fréquence. Je soupçonne que ce soit dû à l’augmentation importante de fréquentation de Matrix après la polémique Discord.
Bonne journée 