Tâche #26261
Scénario #26290: Le service DNS de Samba ne démarre pas à la première instance
Le script postservice/00-actions sort en erreur (timeout) lors du reconfigure d'un module aca.dc1-2.7.0rc2-instance-default
Début:
11/12/2018
Echéance:
% réalisé:
100%
Temps estimé:
4.00 h
Restant à faire (heures):
0.0
Description
run-parts: executing /usr/share/eole/postservice/00-actions reconfigure ++ CreoleGet activer_ead3 non + [[ oui == \o\u\i ]] + echo -e '\n## Synchronisation des modules SaltStack ##' ## Synchronisation des modules SaltStack ## + mkdir -p /srv/salt/_modules/ ++ CreoleGet ead3_upload_path + mkdir -p /var/lib/eole/ead3files + /usr/share/ewt/bin/registeraction.py + '[' '!' 0 = 0 ']' + chown -R salt:salt /srv/salt/ead /srv/salt/_modules /srv/salt/top.sls + salt-call saltutil.sync_modules Attempt to authenticate with the salt master failed with timeout error run-parts: /usr/share/eole/postservice/00-actions exited with return code 1 Erreur : postservice
Révisions associées
“systemd-resolved” is automatically restarted before being configured
This result of a wrong configuration at the first instance preventing
other services to listen on 0.0.0.0:53 like Samba internal DNS
service.
Ref: #26261
systemd-resolved posttemplate should be executable
Ref: #26261
Historique
#1 Mis à jour par Scrum Master il y a plus de 5 ans
- Tâche parente changé de #26198 à #26290
#2 Mis à jour par Daniel Dehennin il y a plus de 5 ans
- Statut changé de Nouveau à En cours
#3 Mis à jour par Daniel Dehennin il y a plus de 5 ans
- Statut changé de En cours à Nouveau
#4 Mis à jour par Daniel Dehennin il y a plus de 5 ans
- Statut changé de Nouveau à En cours
- Assigné à mis à Daniel Dehennin
- Temps estimé mis à 4.00 h
- Restant à faire (heures) mis à 4.0
Le service DNS de samba ne démarre pas car le service systemd-resolved
écoute sur le port 53 de l’adresse 127.0.0.53.
J’ai testé sur eolebase :
- le service
systemd-resolved
est bien arrêté lors de l’instance - il est redémarré avant la génération de son fichier de configuration
- lors de son démarrage rien ne se passe car il est déjà fonctionnel
Voici les logs lors du démarrage prématuré :
déc. 18 11:17:35 eolebase dbus-daemon[546]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.9' (uid=0 pid=1733 comm="/usr/bin/systemd-resolve --status " label="unconfined") déc. 18 11:17:35 eolebase systemd[1]: Starting Network Name Resolution... déc. 18 11:17:35 eolebase systemd-resolved[1734]: Positive Trust Anchors: déc. 18 11:17:35 eolebase systemd-resolved[1734]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 déc. 18 11:17:35 eolebase systemd-resolved[1734]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d déc. 18 11:17:35 eolebase systemd-resolved[1734]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa 168.192.in-addr.arpa d.f.ip6.arpa corp home internal intranet lan local private test déc. 18 11:17:35 eolebase systemd-resolved[1734]: Using system hostname 'eolebase'. déc. 18 11:17:35 eolebase dbus-daemon[546]: [system] Successfully activated service 'org.freedesktop.resolve1' déc. 18 11:17:35 eolebase systemd[1]: Started Network Name Resolution.
#5 Mis à jour par Daniel Dehennin il y a plus de 5 ans
- % réalisé changé de 0 à 100
- Restant à faire (heures) changé de 4.0 à 0.5
#6 Mis à jour par Scrum Master il y a plus de 5 ans
- Statut changé de En cours à Résolu
#7 Mis à jour par Gilles Grandgérard il y a plus de 5 ans
- Statut changé de Résolu à Fermé
- Restant à faire (heures) changé de 0.5 à 0.0