Dnsmasq ne fonctionne pas suite à l'upgrade vers 2.6

Bonjour,
Mon serveur s’est mis à jour vers la version 2.6, je n’ai plus de résolution de nom de domaine sur le serveur car le service
dnasmasq ne démarre pas. Je n’ai pas trouvé de solution sur le forum ni sur le bug tracker, juste cette page qui pourrait me concerner: https://dev.yunohost.org/issues/915

Je connais mal le fonctionnement de dnsmasq et n’arrive pas à débuguer. J’ai lu sur le page du forum qui présente la version 2.6 que maintenant Yunohost utilise aussi le service resolvconf.

Voici ce que ça donne lorsque j’essaie de démarrer le service dnsmasq.

admin@txmrl:~$ sudo service dnsmasq start
Job for dnsmasq.service failed. See 'systemctl status dnsmasq.service' and 'journalctl -xn' for details.
1 admin@txmrl:~$ sudo systemctl status dnsmasq.service
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
   Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled)
  Drop-In: /run/systemd/generator/dnsmasq.service.d
           └─50-dnsmasq-$named.conf, 50-insserv.conf-$named.conf
   Active: failed (Result: timeout) since ven. 2017-06-30 01:47:15 CEST; 4min 52s ago
  Process: 9381 ExecStop=/etc/init.d/dnsmasq systemd-stop-resolvconf (code=killed, signal=TERM)
  Process: 7876 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=0/SUCCESS)
  Process: 7873 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS)
 Main PID: 7882 (code=exited, status=0/SUCCESS)

juin 30 01:44:14 txmrl dnsmasq[7882]: utilise le serveur de nom 213.73.91.35#53
juin 30 01:44:14 txmrl dnsmasq[7882]: utilise le serveur de nom 80.67.169.40#53
juin 30 01:44:14 txmrl dnsmasq[7882]: utilise le serveur de nom 80.67.169.12#53
juin 30 01:44:14 txmrl dnsmasq[7882]: utilise le serveur de nom 89.233.43.71#53
juin 30 01:44:14 txmrl dnsmasq[7882]: lecture /etc/hosts - 7 adresses
juin 30 01:45:44 txmrl systemd[1]: dnsmasq.service start-post operation timed out. Stopping.
juin 30 01:47:15 txmrl systemd[1]: dnsmasq.service stopping timed out. Terminating.
juin 30 01:47:15 txmrl dnsmasq[7882]: sortie sur réception du signal SIGTERM
juin 30 01:47:15 txmrl systemd[1]: Failed to start dnsmasq - A lightweight DHCP and caching DNS server.
juin 30 01:47:15 txmrl systemd[1]: Unit dnsmasq.service entered failed state.
3 admin@txmrl:~$ 

Le démarrage du service, jusqu’au plantage est lent 1 ou 2 minutes, et ce qui est étrange, c’est que pendant ce temps je n’ai plus de problème de résolution de nom de domaine.

Si quelqu’un a une idée, parce que là je ne peux plus ni envoyer ni recevoir de mail et ça commence à devenir très gênant.

Merci par avance.

Pour faire refonctionner mon serveur, j’ai dû désactiver les services resolvconf et dnsmasq et modifier /etc/resolv.conf, mais la la prochaine mise à jour ce sera le même problème.

1 Like

Bonjour,
Je n’ai toujours pas trouvé la source du problème. Personne n’a un idée, sil vous plaît?

Bonjour @tuxmouraille ,

Peut-être un lien avec un envoi de mail toutes les 2 minutes Cron yunohost dyndns update.

ppr

Salut,

ouai, ca me parrait pas impossible que ce soit lié au fait que le dyndns update n’arrive pas à faire sa tambouille…
(Edit : ah, je pensais que c’etait la meme personne qui avait le probleme avec le dyndns … oublions ma remarque :stuck_out_tongue:)

Est-ce que tu as moyen de trouver + d’infos sur pourquoi dnsmasq ne fonctionne pas ? Peut-être en regardant la fin du fichier /var/log/daemon.log (avec tail -n100 /var/log/daemon.log par exemple) après avoir tenté un restart de dnsmasq. Mais en vrai je sais pas trop où dnsmasq stocke ses logs…

Bonsoir @CaptainSqrt2 ,

Oui, c’est la même personne :wink:

Sinon, je viens de faire un service dnsmasq restart qui s’est bien passée.
J’ai également passé la durée du cron dyndns de 30 minutes à 5 minutes pour voir …

Dans le /var/log/daemon.log , sachant que j’ai un domaine.nohost.me , les dernières lignes donnent ça :

Jul 14 20:21:00 domaine systemd[1]: Starting Host and Network Name Lookups.
Jul 14 20:21:00 domaine systemd[1]: Reached target Host and Network Name Lookups.
Jul 14 20:22:46 domaine nslcd[603]: [386575] <passwd=““> request denied by validnames option
Jul 14 20:23:27 domaine nslcd[603]: [f10fd8] <passwd=”
”> request denied by validnames option

J’ai toujours le même email avec :

; TSIG error with server: clocks are unsynchronized
update failed: NOTAUTH(BADTIME)
Impossible de mettre à jour l’adresse IP sur le domaine DynDNS

Sinon je ne comprends pas comment appliquer

ppr

Non mais, a priori y’a pas de rapport avec le dyndns en fait @ppr . Je pensais que c’etait toi aussi qui avait posté cette issue (celle-ci, a propos de dnsmasq) donc qu’il y’avais un lien potentiel à faire avec ton probleme de dyndns update. Mais vous êtes deux personnes différentes /o\

@CaptainSqrt2 pas la même personne mais j’ai ouvert un post et répondu à l’autre.

@CaptainSqrt2 ,

Le cat /etc/dnsmasq.conf donne ça :

domain-needed
expand-hosts
listen-address=127.0.0.1
resolv-file=/etc/resolv.dnsmasq.conf
cache-size=256

ppr

Heu mais je comprends pas ce que tu veux @ppr ? Ici c’est le problème de @tuxmouraille qui a son dnsmasq cassé … À part si je me trompe tu n’as pas le même problème et ton problème est apriori pas lié, donc qu’est-ce que tu essayes de faire ? o.O"

@CaptainSqrt2 ,

Désolé, je reprends le bon topic avec mon histoire de dyndns.
En attendant je pose ça là si ça peut aider : https://superuser.com/questions/681601/verify-dnsmasq-configuration

ppr

@CaptainSqrt2 et @tuxmouraille ,

Juste une idée … est-ce que lors de l’upgrade vers 2.6 il n’y aurait pas eu l’installation de Bind9 qui serait en conflit avec Dnsmasq ?

ppr

Bonjour,
Bind9 n’est pas installé, j’ai bind9host et bind9-utils qui sont des dépendances de dnsmasq et plein d’autres paquets.

Je n’utilise pas dyndns, je loue mon propre nom de domain.

Le problème viens de l’ajout du paquage resolvconf depuis la mise à niveau vers la 2.6.

Bonsoir,
J’ai fini par trouvé que c’est la package squid3 qui fout le bordel, dnsmasq n’arrive pas démarré quand squid3 est installé, d’après le log il doit y a voir un problème de lecture dans la configuration resolvconf pour squid3.

Je vais continuer à creuser, parce que j’ai besoin de squid3.

Bonjour,
Il semble que ce soit un bug connu sous Debian 8 quand on installe dnsmasq, resolvconf et squid3.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798935

Tout refonctionne correctement après avoir remplacé dans le fichier /etc/resolvconf/update-libc.d/squid3invoke-rc.d squid3 reload” par “systemctl --no-block reload squid3.service”.

Donc, l’introduction par défaut de resolvconf dans Yunohost 2.6 a fait bugué la résolution DNS à cause d’un bug dans le paquet squid3 sous Debian dont le service n’a pas été migré vers systemd et qui empêche d’utiliser en même temps dnsmasq, resolvconf et squid3.