Je suppose que c'est systemd qui a attrapé ces logs mais vu que ce n'est
pas du fichier texte et qu'il faut passer par une commande que j'arrive
pas encore à retenir ...
Je suppose que c'est systemd qui a attrapé ces logs mais vu que ce n'est
pas du fichier texte et qu'il faut passer par une commande que j'arrive
pas encore à retenir ...
Je suppose que c'est systemd qui a attrapé ces logs mais vu que ce n'est
pas du fichier texte et qu'il faut passer par une commande que j'arrive
pas encore à retenir ...
Je résume mes besoins :
- avoir la valeur retour du lancement d'un daemon dans le shell au
lancement de la commande service
- avoir les erreurs éventuelles au lancement de la même commande comme avant
- pouvoir désactiver le catch des logs de systemd et laisser le daemon
loguer en syslog comme avant
Je résume mes besoins :
- avoir la valeur retour du lancement d'un daemon dans le shell au
lancement de la commande service
- avoir les erreurs éventuelles au lancement de la même commande comme avant
- pouvoir désactiver le catch des logs de systemd et laisser le daemon
loguer en syslog comme avant
Je résume mes besoins :
- avoir la valeur retour du lancement d'un daemon dans le shell au
lancement de la commande service
- avoir les erreurs éventuelles au lancement de la même commande comme avant
- pouvoir désactiver le catch des logs de systemd et laisser le daemon
loguer en syslog comme avant
Bonjour,
Je tâche depuis la sortie officielle de me dire que si systemd est
fourni c'est qu'il l'est sans bug et sans régression aussi par rapport à
mes tests pré sortie j'essaye de ne plus être négatif sauf que j'ai
vraiment l'impression d'avoir perdu.
Exemple récent, serveur physique chez un hébergeur, installée Jessie, il
est installé par défaut Bind pour la résolution dns, je veux changer et
mettre Unbound à la place.
service bind9 stop
Première remarque avant on savait si un processus était bien démarré ou
éteint là j'en sais strictement rien, mais après tout il pourrait juste
afficher les erreurs et ne rien afficher si tout se passe bien, de plus
mon zsh m'affiche le code retour si il est en erreur et là rien ok.
apt-get install unbound ok pas de soucis
Je télécharge la configuration localhost only que j'ai d'unbound qui
fonctionne sur Debian 6 et 7 et je lance
service unbound start
Là toujours rien d'affiché, mon shell me dit que la commande s'est bien
exécutée mais dans les faits unbound ne s'est pas lancé...
Là pour moi il y a clairement régression, avant j'avais une ligne qui
m'aurait dit erreur au démarrage, là rien et pire le code retour est bon
ce qui fait qu'il est impossible de scripter autour des services de
démarrage ...
Ensuite réflex je fais un tail de /var/log/syslog pour trouver un
message d'erreur et là rien. J'introduis volontairement une ligne non
conforme dans le fichier de configuration pour voir et là rien aussi,
aucun log dans syslog.
Je suppose que c'est systemd qui a attrapé ces logs mais vu que ce n'est
pas du fichier texte et qu'il faut passer par une commande que j'arrive
pas encore à retenir ...
J'ai fait la même erreur dans le fichier config sur Debian 6 et 7 j'ai
bien mes logs et le script de démarrage me précise bien que le processus
n'a pas démarré.
Alors je veux bien me remettre en question mais ça fait beaucoup de
changements non justifiés pour un simple remplacement de système d'init.
Syslog a une utilité et j'aimerais bien qu'il l'a garde.
Alors si vous aviez des conseils sur comment réagir dans ce cas typique
mais tellement anodin qu'il ne devrait même pas être toléré de demander
des conseils je suis preneur.
Je résume mes besoins :
- avoir la valeur retour du lancement d'un daemon dans le shell au
lancement de la commande service
- avoir les erreurs éventuelles au lancement de la même commande comme avant
- pouvoir désactiver le catch des logs de systemd et laisser le daemon
loguer en syslog comme avant
Merci pour votre aide.
-
Bonjour,
Je tâche depuis la sortie officielle de me dire que si systemd est
fourni c'est qu'il l'est sans bug et sans régression aussi par rapport à
mes tests pré sortie j'essaye de ne plus être négatif sauf que j'ai
vraiment l'impression d'avoir perdu.
Exemple récent, serveur physique chez un hébergeur, installée Jessie, il
est installé par défaut Bind pour la résolution dns, je veux changer et
mettre Unbound à la place.
service bind9 stop
Première remarque avant on savait si un processus était bien démarré ou
éteint là j'en sais strictement rien, mais après tout il pourrait juste
afficher les erreurs et ne rien afficher si tout se passe bien, de plus
mon zsh m'affiche le code retour si il est en erreur et là rien ok.
apt-get install unbound ok pas de soucis
Je télécharge la configuration localhost only que j'ai d'unbound qui
fonctionne sur Debian 6 et 7 et je lance
service unbound start
Là toujours rien d'affiché, mon shell me dit que la commande s'est bien
exécutée mais dans les faits unbound ne s'est pas lancé...
Là pour moi il y a clairement régression, avant j'avais une ligne qui
m'aurait dit erreur au démarrage, là rien et pire le code retour est bon
ce qui fait qu'il est impossible de scripter autour des services de
démarrage ...
Ensuite réflex je fais un tail de /var/log/syslog pour trouver un
message d'erreur et là rien. J'introduis volontairement une ligne non
conforme dans le fichier de configuration pour voir et là rien aussi,
aucun log dans syslog.
Je suppose que c'est systemd qui a attrapé ces logs mais vu que ce n'est
pas du fichier texte et qu'il faut passer par une commande que j'arrive
pas encore à retenir ...
J'ai fait la même erreur dans le fichier config sur Debian 6 et 7 j'ai
bien mes logs et le script de démarrage me précise bien que le processus
n'a pas démarré.
Alors je veux bien me remettre en question mais ça fait beaucoup de
changements non justifiés pour un simple remplacement de système d'init.
Syslog a une utilité et j'aimerais bien qu'il l'a garde.
Alors si vous aviez des conseils sur comment réagir dans ce cas typique
mais tellement anodin qu'il ne devrait même pas être toléré de demander
des conseils je suis preneur.
Je résume mes besoins :
- avoir la valeur retour du lancement d'un daemon dans le shell au
lancement de la commande service
- avoir les erreurs éventuelles au lancement de la même commande comme avant
- pouvoir désactiver le catch des logs de systemd et laisser le daemon
loguer en syslog comme avant
Merci pour votre aide.
-
Bonjour,
Je tâche depuis la sortie officielle de me dire que si systemd est
fourni c'est qu'il l'est sans bug et sans régression aussi par rapport à
mes tests pré sortie j'essaye de ne plus être négatif sauf que j'ai
vraiment l'impression d'avoir perdu.
Exemple récent, serveur physique chez un hébergeur, installée Jessie, il
est installé par défaut Bind pour la résolution dns, je veux changer et
mettre Unbound à la place.
service bind9 stop
Première remarque avant on savait si un processus était bien démarré ou
éteint là j'en sais strictement rien, mais après tout il pourrait juste
afficher les erreurs et ne rien afficher si tout se passe bien, de plus
mon zsh m'affiche le code retour si il est en erreur et là rien ok.
apt-get install unbound ok pas de soucis
Je télécharge la configuration localhost only que j'ai d'unbound qui
fonctionne sur Debian 6 et 7 et je lance
service unbound start
Là toujours rien d'affiché, mon shell me dit que la commande s'est bien
exécutée mais dans les faits unbound ne s'est pas lancé...
Là pour moi il y a clairement régression, avant j'avais une ligne qui
m'aurait dit erreur au démarrage, là rien et pire le code retour est bon
ce qui fait qu'il est impossible de scripter autour des services de
démarrage ...
Ensuite réflex je fais un tail de /var/log/syslog pour trouver un
message d'erreur et là rien. J'introduis volontairement une ligne non
conforme dans le fichier de configuration pour voir et là rien aussi,
aucun log dans syslog.
Je suppose que c'est systemd qui a attrapé ces logs mais vu que ce n'est
pas du fichier texte et qu'il faut passer par une commande que j'arrive
pas encore à retenir ...
J'ai fait la même erreur dans le fichier config sur Debian 6 et 7 j'ai
bien mes logs et le script de démarrage me précise bien que le processus
n'a pas démarré.
Alors je veux bien me remettre en question mais ça fait beaucoup de
changements non justifiés pour un simple remplacement de système d'init.
Syslog a une utilité et j'aimerais bien qu'il l'a garde.
Alors si vous aviez des conseils sur comment réagir dans ce cas typique
mais tellement anodin qu'il ne devrait même pas être toléré de demander
des conseils je suis preneur.
Je résume mes besoins :
- avoir la valeur retour du lancement d'un daemon dans le shell au
lancement de la commande service
- avoir les erreurs éventuelles au lancement de la même commande comme avant
- pouvoir désactiver le catch des logs de systemd et laisser le daemon
loguer en syslog comme avant
Merci pour votre aide.
-
Il me semble qu'il est recommandé de remplacer la commande `service` par `systemctl`
Il me semble qu'il est recommandé de remplacer la commande `service` par `systemctl`
Il me semble qu'il est recommandé de remplacer la commande `service` par `systemctl`
Bonsoir,
Le 10/05/2015 14:36, Guillaume a écrit :Il me semble qu'il est recommandé de remplacer la commande `servi ce` par `systemctl`
Perso il me semble avoir lu sur cette liste que, justement, on pouvait
toujours utiliser "service" qui était une sorte de wrapper qui uti lisait
en backend la bonne commande en fonction du système init et que ju stement
c'était très bien comme ça car on n'avait pas à s'e mbêter. Du coup, les
questions du PO me semblent légitimes. Je n'ai aucune réponse en l'occurrence
vu que j'y connais rien encore à systemd.
Bonsoir,
Le 10/05/2015 14:36, Guillaume a écrit :
Il me semble qu'il est recommandé de remplacer la commande `servi ce` par `systemctl`
Perso il me semble avoir lu sur cette liste que, justement, on pouvait
toujours utiliser "service" qui était une sorte de wrapper qui uti lisait
en backend la bonne commande en fonction du système init et que ju stement
c'était très bien comme ça car on n'avait pas à s'e mbêter. Du coup, les
questions du PO me semblent légitimes. Je n'ai aucune réponse en l'occurrence
vu que j'y connais rien encore à systemd.
Bonsoir,
Le 10/05/2015 14:36, Guillaume a écrit :Il me semble qu'il est recommandé de remplacer la commande `servi ce` par `systemctl`
Perso il me semble avoir lu sur cette liste que, justement, on pouvait
toujours utiliser "service" qui était une sorte de wrapper qui uti lisait
en backend la bonne commande en fonction du système init et que ju stement
c'était très bien comme ça car on n'avait pas à s'e mbêter. Du coup, les
questions du PO me semblent légitimes. Je n'ai aucune réponse en l'occurrence
vu que j'y connais rien encore à systemd.
Bonjour,
Je tâche depuis la sortie officielle de me dire que si systemd est
fourni c'est qu'il l'est sans bug et sans régression aussi par rapport à
mes tests pré sortie j'essaye de ne plus être négatif sauf que j'ai
vraiment l'impression d'avoir perdu.
Exemple récent, serveur physique chez un hébergeur, installée Jessie, il
est installé par défaut Bind pour la résolution dns, je veux changer et
mettre Unbound à la place.
service bind9 stop
Première remarque avant on savait si un processus était bien démarré ou
éteint là j'en sais strictement rien, mais après tout il pourrait juste
afficher les erreurs et ne rien afficher si tout se passe bien, de plus
mon zsh m'affiche le code retour si il est en erreur et là rien ok.
apt-get install unbound ok pas de soucis
Je télécharge la configuration localhost only que j'ai d'unbound qui
fonctionne sur Debian 6 et 7 et je lance
service unbound start
Là toujours rien d'affiché, mon shell me dit que la commande s'est bien
exécutée mais dans les faits unbound ne s'est pas lancé...
Là pour moi il y a clairement régression, avant j'avais une ligne qui
m'aurait dit erreur au démarrage, là rien et pire le code retour est bon
ce qui fait qu'il est impossible de scripter autour des services de
démarrage ...
Ensuite réflex je fais un tail de /var/log/syslog pour trouver un
message d'erreur et là rien. J'introduis volontairement une ligne non
conforme dans le fichier de configuration pour voir et là rien aussi,
aucun log dans syslog.
Je suppose que c'est systemd qui a attrapé ces logs mais vu que ce n'est
pas du fichier texte et qu'il faut passer par une commande que j'arrive
pas encore à retenir ...
J'ai fait la même erreur dans le fichier config sur Debian 6 et 7 j'ai
bien mes logs et le script de démarrage me précise bien que le processus
n'a pas démarré.
Bonjour,
Je tâche depuis la sortie officielle de me dire que si systemd est
fourni c'est qu'il l'est sans bug et sans régression aussi par rapport à
mes tests pré sortie j'essaye de ne plus être négatif sauf que j'ai
vraiment l'impression d'avoir perdu.
Exemple récent, serveur physique chez un hébergeur, installée Jessie, il
est installé par défaut Bind pour la résolution dns, je veux changer et
mettre Unbound à la place.
service bind9 stop
Première remarque avant on savait si un processus était bien démarré ou
éteint là j'en sais strictement rien, mais après tout il pourrait juste
afficher les erreurs et ne rien afficher si tout se passe bien, de plus
mon zsh m'affiche le code retour si il est en erreur et là rien ok.
apt-get install unbound ok pas de soucis
Je télécharge la configuration localhost only que j'ai d'unbound qui
fonctionne sur Debian 6 et 7 et je lance
service unbound start
Là toujours rien d'affiché, mon shell me dit que la commande s'est bien
exécutée mais dans les faits unbound ne s'est pas lancé...
Là pour moi il y a clairement régression, avant j'avais une ligne qui
m'aurait dit erreur au démarrage, là rien et pire le code retour est bon
ce qui fait qu'il est impossible de scripter autour des services de
démarrage ...
Ensuite réflex je fais un tail de /var/log/syslog pour trouver un
message d'erreur et là rien. J'introduis volontairement une ligne non
conforme dans le fichier de configuration pour voir et là rien aussi,
aucun log dans syslog.
Je suppose que c'est systemd qui a attrapé ces logs mais vu que ce n'est
pas du fichier texte et qu'il faut passer par une commande que j'arrive
pas encore à retenir ...
J'ai fait la même erreur dans le fichier config sur Debian 6 et 7 j'ai
bien mes logs et le script de démarrage me précise bien que le processus
n'a pas démarré.
Bonjour,
Je tâche depuis la sortie officielle de me dire que si systemd est
fourni c'est qu'il l'est sans bug et sans régression aussi par rapport à
mes tests pré sortie j'essaye de ne plus être négatif sauf que j'ai
vraiment l'impression d'avoir perdu.
Exemple récent, serveur physique chez un hébergeur, installée Jessie, il
est installé par défaut Bind pour la résolution dns, je veux changer et
mettre Unbound à la place.
service bind9 stop
Première remarque avant on savait si un processus était bien démarré ou
éteint là j'en sais strictement rien, mais après tout il pourrait juste
afficher les erreurs et ne rien afficher si tout se passe bien, de plus
mon zsh m'affiche le code retour si il est en erreur et là rien ok.
apt-get install unbound ok pas de soucis
Je télécharge la configuration localhost only que j'ai d'unbound qui
fonctionne sur Debian 6 et 7 et je lance
service unbound start
Là toujours rien d'affiché, mon shell me dit que la commande s'est bien
exécutée mais dans les faits unbound ne s'est pas lancé...
Là pour moi il y a clairement régression, avant j'avais une ligne qui
m'aurait dit erreur au démarrage, là rien et pire le code retour est bon
ce qui fait qu'il est impossible de scripter autour des services de
démarrage ...
Ensuite réflex je fais un tail de /var/log/syslog pour trouver un
message d'erreur et là rien. J'introduis volontairement une ligne non
conforme dans le fichier de configuration pour voir et là rien aussi,
aucun log dans syslog.
Je suppose que c'est systemd qui a attrapé ces logs mais vu que ce n'est
pas du fichier texte et qu'il faut passer par une commande que j'arrive
pas encore à retenir ...
J'ai fait la même erreur dans le fichier config sur Debian 6 et 7 j'ai
bien mes logs et le script de démarrage me précise bien que le processus
n'a pas démarré.
On 10/05/15 at 11:38 +0200, Wallace wrote:Bonjour,
Je tâche depuis la sortie officielle de me dire que si systemd es t
fourni c'est qu'il l'est sans bug et sans régression aussi par ra pport Ã
mes tests pré sortie j'essaye de ne plus être négatif s auf que j'ai
vraiment l'impression d'avoir perdu.
Exemple récent, serveur physique chez un hébergeur, installà ©e Jessie, il
est installé par défaut Bind pour la résolution dns, je veux changer et
mettre Unbound à la place.
service bind9 stop
Première remarque avant on savait si un processus était bien démarré ou
éteint là j'en sais strictement rien, mais après tout i l pourrait juste
afficher les erreurs et ne rien afficher si tout se passe bien, de plu s
mon zsh m'affiche le code retour si il est en erreur et là rien o k.
apt-get install unbound ok pas de soucis
Je télécharge la configuration localhost only que j'ai d'unb ound qui
fonctionne sur Debian 6 et 7 et je lance
service unbound start
Là toujours rien d'affiché, mon shell me dit que la commande s'est bien
exécutée mais dans les faits unbound ne s'est pas lancé ...
Là pour moi il y a clairement régression, avant j'avais une ligne qui
m'aurait dit erreur au démarrage, là rien et pire le code re tour est bon
ce qui fait qu'il est impossible de scripter autour des services de
démarrage ...
En fait, ça dépend des cas.
Dans ton cas (erreur de configuration), le service est bien démarr é,
mais juste après avoir démarré, il lit sa configuration, découvre
qu'elle est fausse, et sort immédiatement. Le problème, c'est que comme
le service avait bien démarré, systemctl ou 'service' avait d éjÃ
retourné que tout s'était bien passé.
Avec sysvinit, ça fonctionnait un peu différemment: comme le service
plantait avant de forker, start-stop-daemon détectait qu'il planta it et
affichait un message d'erreur. (qui d'ailleurs, ne résulte pas en un
code de retour différent de 0)
La "bonne" solution avec systemd serait probablement que unbound
"prévienne" systemd qu'il s'est correctement initialisé. C'es t possible
avec un Type=notify, et systemd-notify / sd_notify.
Mais à part ça, c'est dur de trouver une solution: combien de temps
systemd devrait-il attendre après le lancement d'un service pour
conclure que "c'est bon, il tourne depuis X secondes, on peut dire que
s'il a a pas planté jusque là , il fonctionne vraiment!" ?
Ensuite réflex je fais un tail de /var/log/syslog pour trouver un
message d'erreur et là rien. J'introduis volontairement une ligne non
conforme dans le fichier de configuration pour voir et là rien au ssi,
aucun log dans syslog.
Je suppose que c'est systemd qui a attrapé ces logs mais vu que c e n'est
pas du fichier texte et qu'il faut passer par une commande que j'arriv e
pas encore à retenir ...
J'ai fait la même erreur dans le fichier config sur Debian 6 et 7 j'ai
bien mes logs et le script de démarrage me précise bien que le processus
n'a pas démarré.
Alors ça, par contre, ça m'étonne beaucoup. J'ai testà ©:
J'ai modifié /etc/unbound/unbound.conf pour y ajouter une erreur.
J'ai redémarré unbound (service unbound restart).
Je n'ai pas de message d'erreur à cause du problème ci-dessus .
Mais avec 'service unbound status, qui appelle en fait 'systemctl statu s
unbound', j'ai bien l'extrait de log:
# service unbound status
â unbound.service - (null)
Loaded: loaded (/etc/init.d/unbound)
Drop-In: /run/systemd/generator/unbound.service.d
ââ50-insserv.conf-$named.conf, 50-unbound-$n amed.conf
Active: active (exited) since Tue 2015-05-12 10:44:36 CEST; 1min 17s ago
Process: 1827 ExecStop=/etc/init.d/unbound stop (code=exited, sta tus=0/SUCCESS)
Process: 1834 ExecStart=/etc/init.d/unbound start (code=exited, s tatus=0/SUCCESS)
May 12 10:44:36 debian unbound-anchor[1843]: /var/lib/unbound/root.key has content
May 12 10:44:36 debian unbound-anchor[1843]: success: the anchor is ok
May 12 10:44:36 debian unbound[1834]: Starting recursive DNS server: un bound/etc/unbound/unbound....qqd'
May 12 10:44:36 debian unbound[1834]: read /etc/unbound/unbound.conf fa iled: 1 errors in configur...file
May 12 10:44:36 debian unbound[1834]: [1431420276] unbound[1845:0] fata l error: Could not read co...conf
May 12 10:44:36 debian unbound[1834]: failed!
Hint: Some lines were ellipsized, use -l to show in full.
J'ai les mêmes messages avec 'journalctl', et dans /var/log/syslog
Aurais-tu désactivé la redirection vers syslog, par hasard ? (ForwardToSyslog= dans /etc/systemd/journald.conf)
On 10/05/15 at 11:38 +0200, Wallace wrote:
Bonjour,
Je tâche depuis la sortie officielle de me dire que si systemd es t
fourni c'est qu'il l'est sans bug et sans régression aussi par ra pport Ã
mes tests pré sortie j'essaye de ne plus être négatif s auf que j'ai
vraiment l'impression d'avoir perdu.
Exemple récent, serveur physique chez un hébergeur, installà ©e Jessie, il
est installé par défaut Bind pour la résolution dns, je veux changer et
mettre Unbound à la place.
service bind9 stop
Première remarque avant on savait si un processus était bien démarré ou
éteint là j'en sais strictement rien, mais après tout i l pourrait juste
afficher les erreurs et ne rien afficher si tout se passe bien, de plu s
mon zsh m'affiche le code retour si il est en erreur et là rien o k.
apt-get install unbound ok pas de soucis
Je télécharge la configuration localhost only que j'ai d'unb ound qui
fonctionne sur Debian 6 et 7 et je lance
service unbound start
Là toujours rien d'affiché, mon shell me dit que la commande s'est bien
exécutée mais dans les faits unbound ne s'est pas lancé ...
Là pour moi il y a clairement régression, avant j'avais une ligne qui
m'aurait dit erreur au démarrage, là rien et pire le code re tour est bon
ce qui fait qu'il est impossible de scripter autour des services de
démarrage ...
En fait, ça dépend des cas.
Dans ton cas (erreur de configuration), le service est bien démarr é,
mais juste après avoir démarré, il lit sa configuration, découvre
qu'elle est fausse, et sort immédiatement. Le problème, c'est que comme
le service avait bien démarré, systemctl ou 'service' avait d éjÃ
retourné que tout s'était bien passé.
Avec sysvinit, ça fonctionnait un peu différemment: comme le service
plantait avant de forker, start-stop-daemon détectait qu'il planta it et
affichait un message d'erreur. (qui d'ailleurs, ne résulte pas en un
code de retour différent de 0)
La "bonne" solution avec systemd serait probablement que unbound
"prévienne" systemd qu'il s'est correctement initialisé. C'es t possible
avec un Type=notify, et systemd-notify / sd_notify.
Mais à part ça, c'est dur de trouver une solution: combien de temps
systemd devrait-il attendre après le lancement d'un service pour
conclure que "c'est bon, il tourne depuis X secondes, on peut dire que
s'il a a pas planté jusque là , il fonctionne vraiment!" ?
Ensuite réflex je fais un tail de /var/log/syslog pour trouver un
message d'erreur et là rien. J'introduis volontairement une ligne non
conforme dans le fichier de configuration pour voir et là rien au ssi,
aucun log dans syslog.
Je suppose que c'est systemd qui a attrapé ces logs mais vu que c e n'est
pas du fichier texte et qu'il faut passer par une commande que j'arriv e
pas encore à retenir ...
J'ai fait la même erreur dans le fichier config sur Debian 6 et 7 j'ai
bien mes logs et le script de démarrage me précise bien que le processus
n'a pas démarré.
Alors ça, par contre, ça m'étonne beaucoup. J'ai testà ©:
J'ai modifié /etc/unbound/unbound.conf pour y ajouter une erreur.
J'ai redémarré unbound (service unbound restart).
Je n'ai pas de message d'erreur à cause du problème ci-dessus .
Mais avec 'service unbound status, qui appelle en fait 'systemctl statu s
unbound', j'ai bien l'extrait de log:
# service unbound status
â unbound.service - (null)
Loaded: loaded (/etc/init.d/unbound)
Drop-In: /run/systemd/generator/unbound.service.d
ââ50-insserv.conf-$named.conf, 50-unbound-$n amed.conf
Active: active (exited) since Tue 2015-05-12 10:44:36 CEST; 1min 17s ago
Process: 1827 ExecStop=/etc/init.d/unbound stop (code=exited, sta tus=0/SUCCESS)
Process: 1834 ExecStart=/etc/init.d/unbound start (code=exited, s tatus=0/SUCCESS)
May 12 10:44:36 debian unbound-anchor[1843]: /var/lib/unbound/root.key has content
May 12 10:44:36 debian unbound-anchor[1843]: success: the anchor is ok
May 12 10:44:36 debian unbound[1834]: Starting recursive DNS server: un bound/etc/unbound/unbound....qqd'
May 12 10:44:36 debian unbound[1834]: read /etc/unbound/unbound.conf fa iled: 1 errors in configur...file
May 12 10:44:36 debian unbound[1834]: [1431420276] unbound[1845:0] fata l error: Could not read co...conf
May 12 10:44:36 debian unbound[1834]: failed!
Hint: Some lines were ellipsized, use -l to show in full.
J'ai les mêmes messages avec 'journalctl', et dans /var/log/syslog
Aurais-tu désactivé la redirection vers syslog, par hasard ? (ForwardToSyslog= dans /etc/systemd/journald.conf)
On 10/05/15 at 11:38 +0200, Wallace wrote:Bonjour,
Je tâche depuis la sortie officielle de me dire que si systemd es t
fourni c'est qu'il l'est sans bug et sans régression aussi par ra pport Ã
mes tests pré sortie j'essaye de ne plus être négatif s auf que j'ai
vraiment l'impression d'avoir perdu.
Exemple récent, serveur physique chez un hébergeur, installà ©e Jessie, il
est installé par défaut Bind pour la résolution dns, je veux changer et
mettre Unbound à la place.
service bind9 stop
Première remarque avant on savait si un processus était bien démarré ou
éteint là j'en sais strictement rien, mais après tout i l pourrait juste
afficher les erreurs et ne rien afficher si tout se passe bien, de plu s
mon zsh m'affiche le code retour si il est en erreur et là rien o k.
apt-get install unbound ok pas de soucis
Je télécharge la configuration localhost only que j'ai d'unb ound qui
fonctionne sur Debian 6 et 7 et je lance
service unbound start
Là toujours rien d'affiché, mon shell me dit que la commande s'est bien
exécutée mais dans les faits unbound ne s'est pas lancé ...
Là pour moi il y a clairement régression, avant j'avais une ligne qui
m'aurait dit erreur au démarrage, là rien et pire le code re tour est bon
ce qui fait qu'il est impossible de scripter autour des services de
démarrage ...
En fait, ça dépend des cas.
Dans ton cas (erreur de configuration), le service est bien démarr é,
mais juste après avoir démarré, il lit sa configuration, découvre
qu'elle est fausse, et sort immédiatement. Le problème, c'est que comme
le service avait bien démarré, systemctl ou 'service' avait d éjÃ
retourné que tout s'était bien passé.
Avec sysvinit, ça fonctionnait un peu différemment: comme le service
plantait avant de forker, start-stop-daemon détectait qu'il planta it et
affichait un message d'erreur. (qui d'ailleurs, ne résulte pas en un
code de retour différent de 0)
La "bonne" solution avec systemd serait probablement que unbound
"prévienne" systemd qu'il s'est correctement initialisé. C'es t possible
avec un Type=notify, et systemd-notify / sd_notify.
Mais à part ça, c'est dur de trouver une solution: combien de temps
systemd devrait-il attendre après le lancement d'un service pour
conclure que "c'est bon, il tourne depuis X secondes, on peut dire que
s'il a a pas planté jusque là , il fonctionne vraiment!" ?
Ensuite réflex je fais un tail de /var/log/syslog pour trouver un
message d'erreur et là rien. J'introduis volontairement une ligne non
conforme dans le fichier de configuration pour voir et là rien au ssi,
aucun log dans syslog.
Je suppose que c'est systemd qui a attrapé ces logs mais vu que c e n'est
pas du fichier texte et qu'il faut passer par une commande que j'arriv e
pas encore à retenir ...
J'ai fait la même erreur dans le fichier config sur Debian 6 et 7 j'ai
bien mes logs et le script de démarrage me précise bien que le processus
n'a pas démarré.
Alors ça, par contre, ça m'étonne beaucoup. J'ai testà ©:
J'ai modifié /etc/unbound/unbound.conf pour y ajouter une erreur.
J'ai redémarré unbound (service unbound restart).
Je n'ai pas de message d'erreur à cause du problème ci-dessus .
Mais avec 'service unbound status, qui appelle en fait 'systemctl statu s
unbound', j'ai bien l'extrait de log:
# service unbound status
â unbound.service - (null)
Loaded: loaded (/etc/init.d/unbound)
Drop-In: /run/systemd/generator/unbound.service.d
ââ50-insserv.conf-$named.conf, 50-unbound-$n amed.conf
Active: active (exited) since Tue 2015-05-12 10:44:36 CEST; 1min 17s ago
Process: 1827 ExecStop=/etc/init.d/unbound stop (code=exited, sta tus=0/SUCCESS)
Process: 1834 ExecStart=/etc/init.d/unbound start (code=exited, s tatus=0/SUCCESS)
May 12 10:44:36 debian unbound-anchor[1843]: /var/lib/unbound/root.key has content
May 12 10:44:36 debian unbound-anchor[1843]: success: the anchor is ok
May 12 10:44:36 debian unbound[1834]: Starting recursive DNS server: un bound/etc/unbound/unbound....qqd'
May 12 10:44:36 debian unbound[1834]: read /etc/unbound/unbound.conf fa iled: 1 errors in configur...file
May 12 10:44:36 debian unbound[1834]: [1431420276] unbound[1845:0] fata l error: Could not read co...conf
May 12 10:44:36 debian unbound[1834]: failed!
Hint: Some lines were ellipsized, use -l to show in full.
J'ai les mêmes messages avec 'journalctl', et dans /var/log/syslog
Aurais-tu désactivé la redirection vers syslog, par hasard ? (ForwardToSyslog= dans /etc/systemd/journald.conf)
Le 12/05/2015 10:58, Lucas Nussbaum a écrit :On 10/05/15 at 11:38 +0200, Wallace wrote:Bonjour,
Je tâche depuis la sortie officielle de me dire que si systemd est
fourni c'est qu'il l'est sans bug et sans régression aussi par rapport à
mes tests pré sortie j'essaye de ne plus être négatif sauf que j'ai
vraiment l'impression d'avoir perdu.
Exemple récent, serveur physique chez un hébergeur, installée Jessie, il
est installé par défaut Bind pour la résolution dns, je veux changer et
mettre Unbound à la place.
service bind9 stop
Première remarque avant on savait si un processus était bien démarré ou
éteint là j'en sais strictement rien, mais après tout il pourrait juste
afficher les erreurs et ne rien afficher si tout se passe bien, de plus
mon zsh m'affiche le code retour si il est en erreur et là rien ok.
apt-get install unbound ok pas de soucis
Je télécharge la configuration localhost only que j'ai d'unbound qui
fonctionne sur Debian 6 et 7 et je lance
service unbound start
Là toujours rien d'affiché, mon shell me dit que la commande s'est bien
exécutée mais dans les faits unbound ne s'est pas lancé...
Là pour moi il y a clairement régression, avant j'avais une ligne qui
m'aurait dit erreur au démarrage, là rien et pire le code retour est bon
ce qui fait qu'il est impossible de scripter autour des services de
démarrage ...
Merci pour ton retour et tes explications.En fait, ça dépend des cas.
Dans ton cas (erreur de configuration), le service est bien démarré,
mais juste après avoir démarré, il lit sa configuration, découvre
qu'elle est fausse, et sort immédiatement. Le problème, c'est que comme
le service avait bien démarré, systemctl ou 'service' avait déjà
retourné que tout s'était bien passé.
Je le prend vraiment comme une régression et je vois déjà les problèmes
que cela va apporter lorsque humainement on se dira tout va bien je n'ai
pas fait de modification sur ce daemon et on va le lancer sans se rendre
compte qu'il n'est pas correctement démarré parce qu'une évolution du
logiciel a fait déprécier des options par exemple.
Avec sysvinit, ça fonctionnait un peu différemment: comme le service
plantait avant de forker, start-stop-daemon détectait qu'il plantait et
affichait un message d'erreur. (qui d'ailleurs, ne résulte pas en un
code de retour différent de 0)
La "bonne" solution avec systemd serait probablement que unbound
"prévienne" systemd qu'il s'est correctement initialisé. C'est possible
avec un Type=notify, et systemd-notify / sd_notify.
Mais à part ça, c'est dur de trouver une solution: combien de temps
systemd devrait-il attendre après le lancement d'un service pour
conclure que "c'est bon, il tourne depuis X secondes, on peut dire que
s'il a a pas planté jusque là, il fonctionne vraiment!" ?
Cela met bien en évidence les faiblesses de ce système quand un fork
était plus logique dans le contrôle des processus.
Le timeout va dépendre pas mal du type de logiciel, par exemple une base
de donnée qui doit faire des vérifications au démarrage cela peut
prendre pas mal de temps. De ce point de vue sysvinit avait déjà ses
limites, un timeout existait et j'ai souvent vu des mysql mettre du
temps à démarrer et avoir un retour comme quoi le processus n'était pas
lancé alors qu'il n'avait juste pas fini ses traitements.
L'envoie du signal par l'application, pourquoi pas mais je vois mal
toutes les applications en mode daemon faire des modifications dans ce
sens sachant qu'après tout chacun est libre de choisir son init. Déjà
que la plupart des progiciels en entreprises préconisent un lancement
manuel à chaque démarrage et que depuis tant d'année faire un script
sysvinit cela semble trop compliqué pour eux ... Il va y avoir vraiment
deux mondes, les binaires aptes à communiquer avec systemd et les autres
... ça sera vraiment dommageable.Ensuite réflex je fais un tail de /var/log/syslog pour trouver un
message d'erreur et là rien. J'introduis volontairement une ligne non
conforme dans le fichier de configuration pour voir et là rien aussi,
aucun log dans syslog.
Je suppose que c'est systemd qui a attrapé ces logs mais vu que ce n'est
pas du fichier texte et qu'il faut passer par une commande que j'arrive
pas encore à retenir ...
J'ai fait la même erreur dans le fichier config sur Debian 6 et 7 j'ai
bien mes logs et le script de démarrage me précise bien que le processus
n'a pas démarré.
Alors ça, par contre, ça m'étonne beaucoup. J'ai testé:
J'ai modifié /etc/unbound/unbound.conf pour y ajouter une erreur.
J'ai redémarré unbound (service unbound restart).
Je n'ai pas de message d'erreur à cause du problème ci-dessus.
Mais avec 'service unbound status, qui appelle en fait 'systemctl status
unbound', j'ai bien l'extrait de log:
# service unbound status
● unbound.service - (null)
Loaded: loaded (/etc/init.d/unbound)
Drop-In: /run/systemd/generator/unbound.service.d
└─50-insserv.conf-$named.conf, 50-unbound-$named.conf
Active: active (exited) since Tue 2015-05-12 10:44:36 CEST; 1min 17s ago
Process: 1827 ExecStop=/etc/init.d/unbound stop (code=exited, status=0/SUCCESS)
Process: 1834 ExecStart=/etc/init.d/unbound start (code=exited, status=0/SUCCESS)
May 12 10:44:36 debian unbound-anchor[1843]: /var/lib/unbound/root.key has content
May 12 10:44:36 debian unbound-anchor[1843]: success: the anchor is ok
May 12 10:44:36 debian unbound[1834]: Starting recursive DNS server: unbound/etc/unbound/unbound....qqd'
May 12 10:44:36 debian unbound[1834]: read /etc/unbound/unbound.conf failed: 1 errors in configur...file
May 12 10:44:36 debian unbound[1834]: [1431420276] unbound[1845:0] fatal error: Could not read co...conf
May 12 10:44:36 debian unbound[1834]: failed!
Hint: Some lines were ellipsized, use -l to show in full.
Là ça commence à parler et à prendre forme, mais effectivement faut
changer ses habitudes j'utilise rarement status avec service car tous
les daemons ne l'implémentent pas, cela aurait été tellement plus simple
d'avoir une erreur après le start.
J'ai les mêmes messages avec 'journalctl', et dans /var/log/syslog
Aurais-tu désactivé la redirection vers syslog, par hasard ? (ForwardToSyslog= dans /etc/systemd/journald.conf)
La Debian 8 en question est toute neuve, je vais regarder si
l'installation fournie par le prestataire ne désactive pas des éléments
syslog mais je doute ça serait assez mal venu de faire cela.
Encore merci pour tes explications
Le 12/05/2015 10:58, Lucas Nussbaum a écrit :
On 10/05/15 at 11:38 +0200, Wallace wrote:
Bonjour,
Je tâche depuis la sortie officielle de me dire que si systemd est
fourni c'est qu'il l'est sans bug et sans régression aussi par rapport à
mes tests pré sortie j'essaye de ne plus être négatif sauf que j'ai
vraiment l'impression d'avoir perdu.
Exemple récent, serveur physique chez un hébergeur, installée Jessie, il
est installé par défaut Bind pour la résolution dns, je veux changer et
mettre Unbound à la place.
service bind9 stop
Première remarque avant on savait si un processus était bien démarré ou
éteint là j'en sais strictement rien, mais après tout il pourrait juste
afficher les erreurs et ne rien afficher si tout se passe bien, de plus
mon zsh m'affiche le code retour si il est en erreur et là rien ok.
apt-get install unbound ok pas de soucis
Je télécharge la configuration localhost only que j'ai d'unbound qui
fonctionne sur Debian 6 et 7 et je lance
service unbound start
Là toujours rien d'affiché, mon shell me dit que la commande s'est bien
exécutée mais dans les faits unbound ne s'est pas lancé...
Là pour moi il y a clairement régression, avant j'avais une ligne qui
m'aurait dit erreur au démarrage, là rien et pire le code retour est bon
ce qui fait qu'il est impossible de scripter autour des services de
démarrage ...
Merci pour ton retour et tes explications.
En fait, ça dépend des cas.
Dans ton cas (erreur de configuration), le service est bien démarré,
mais juste après avoir démarré, il lit sa configuration, découvre
qu'elle est fausse, et sort immédiatement. Le problème, c'est que comme
le service avait bien démarré, systemctl ou 'service' avait déjà
retourné que tout s'était bien passé.
Je le prend vraiment comme une régression et je vois déjà les problèmes
que cela va apporter lorsque humainement on se dira tout va bien je n'ai
pas fait de modification sur ce daemon et on va le lancer sans se rendre
compte qu'il n'est pas correctement démarré parce qu'une évolution du
logiciel a fait déprécier des options par exemple.
Avec sysvinit, ça fonctionnait un peu différemment: comme le service
plantait avant de forker, start-stop-daemon détectait qu'il plantait et
affichait un message d'erreur. (qui d'ailleurs, ne résulte pas en un
code de retour différent de 0)
La "bonne" solution avec systemd serait probablement que unbound
"prévienne" systemd qu'il s'est correctement initialisé. C'est possible
avec un Type=notify, et systemd-notify / sd_notify.
Mais à part ça, c'est dur de trouver une solution: combien de temps
systemd devrait-il attendre après le lancement d'un service pour
conclure que "c'est bon, il tourne depuis X secondes, on peut dire que
s'il a a pas planté jusque là, il fonctionne vraiment!" ?
Cela met bien en évidence les faiblesses de ce système quand un fork
était plus logique dans le contrôle des processus.
Le timeout va dépendre pas mal du type de logiciel, par exemple une base
de donnée qui doit faire des vérifications au démarrage cela peut
prendre pas mal de temps. De ce point de vue sysvinit avait déjà ses
limites, un timeout existait et j'ai souvent vu des mysql mettre du
temps à démarrer et avoir un retour comme quoi le processus n'était pas
lancé alors qu'il n'avait juste pas fini ses traitements.
L'envoie du signal par l'application, pourquoi pas mais je vois mal
toutes les applications en mode daemon faire des modifications dans ce
sens sachant qu'après tout chacun est libre de choisir son init. Déjà
que la plupart des progiciels en entreprises préconisent un lancement
manuel à chaque démarrage et que depuis tant d'année faire un script
sysvinit cela semble trop compliqué pour eux ... Il va y avoir vraiment
deux mondes, les binaires aptes à communiquer avec systemd et les autres
... ça sera vraiment dommageable.
Ensuite réflex je fais un tail de /var/log/syslog pour trouver un
message d'erreur et là rien. J'introduis volontairement une ligne non
conforme dans le fichier de configuration pour voir et là rien aussi,
aucun log dans syslog.
Je suppose que c'est systemd qui a attrapé ces logs mais vu que ce n'est
pas du fichier texte et qu'il faut passer par une commande que j'arrive
pas encore à retenir ...
J'ai fait la même erreur dans le fichier config sur Debian 6 et 7 j'ai
bien mes logs et le script de démarrage me précise bien que le processus
n'a pas démarré.
Alors ça, par contre, ça m'étonne beaucoup. J'ai testé:
J'ai modifié /etc/unbound/unbound.conf pour y ajouter une erreur.
J'ai redémarré unbound (service unbound restart).
Je n'ai pas de message d'erreur à cause du problème ci-dessus.
Mais avec 'service unbound status, qui appelle en fait 'systemctl status
unbound', j'ai bien l'extrait de log:
# service unbound status
● unbound.service - (null)
Loaded: loaded (/etc/init.d/unbound)
Drop-In: /run/systemd/generator/unbound.service.d
└─50-insserv.conf-$named.conf, 50-unbound-$named.conf
Active: active (exited) since Tue 2015-05-12 10:44:36 CEST; 1min 17s ago
Process: 1827 ExecStop=/etc/init.d/unbound stop (code=exited, status=0/SUCCESS)
Process: 1834 ExecStart=/etc/init.d/unbound start (code=exited, status=0/SUCCESS)
May 12 10:44:36 debian unbound-anchor[1843]: /var/lib/unbound/root.key has content
May 12 10:44:36 debian unbound-anchor[1843]: success: the anchor is ok
May 12 10:44:36 debian unbound[1834]: Starting recursive DNS server: unbound/etc/unbound/unbound....qqd'
May 12 10:44:36 debian unbound[1834]: read /etc/unbound/unbound.conf failed: 1 errors in configur...file
May 12 10:44:36 debian unbound[1834]: [1431420276] unbound[1845:0] fatal error: Could not read co...conf
May 12 10:44:36 debian unbound[1834]: failed!
Hint: Some lines were ellipsized, use -l to show in full.
Là ça commence à parler et à prendre forme, mais effectivement faut
changer ses habitudes j'utilise rarement status avec service car tous
les daemons ne l'implémentent pas, cela aurait été tellement plus simple
d'avoir une erreur après le start.
J'ai les mêmes messages avec 'journalctl', et dans /var/log/syslog
Aurais-tu désactivé la redirection vers syslog, par hasard ? (ForwardToSyslog= dans /etc/systemd/journald.conf)
La Debian 8 en question est toute neuve, je vais regarder si
l'installation fournie par le prestataire ne désactive pas des éléments
syslog mais je doute ça serait assez mal venu de faire cela.
Encore merci pour tes explications
Le 12/05/2015 10:58, Lucas Nussbaum a écrit :On 10/05/15 at 11:38 +0200, Wallace wrote:Bonjour,
Je tâche depuis la sortie officielle de me dire que si systemd est
fourni c'est qu'il l'est sans bug et sans régression aussi par rapport à
mes tests pré sortie j'essaye de ne plus être négatif sauf que j'ai
vraiment l'impression d'avoir perdu.
Exemple récent, serveur physique chez un hébergeur, installée Jessie, il
est installé par défaut Bind pour la résolution dns, je veux changer et
mettre Unbound à la place.
service bind9 stop
Première remarque avant on savait si un processus était bien démarré ou
éteint là j'en sais strictement rien, mais après tout il pourrait juste
afficher les erreurs et ne rien afficher si tout se passe bien, de plus
mon zsh m'affiche le code retour si il est en erreur et là rien ok.
apt-get install unbound ok pas de soucis
Je télécharge la configuration localhost only que j'ai d'unbound qui
fonctionne sur Debian 6 et 7 et je lance
service unbound start
Là toujours rien d'affiché, mon shell me dit que la commande s'est bien
exécutée mais dans les faits unbound ne s'est pas lancé...
Là pour moi il y a clairement régression, avant j'avais une ligne qui
m'aurait dit erreur au démarrage, là rien et pire le code retour est bon
ce qui fait qu'il est impossible de scripter autour des services de
démarrage ...
Merci pour ton retour et tes explications.En fait, ça dépend des cas.
Dans ton cas (erreur de configuration), le service est bien démarré,
mais juste après avoir démarré, il lit sa configuration, découvre
qu'elle est fausse, et sort immédiatement. Le problème, c'est que comme
le service avait bien démarré, systemctl ou 'service' avait déjà
retourné que tout s'était bien passé.
Je le prend vraiment comme une régression et je vois déjà les problèmes
que cela va apporter lorsque humainement on se dira tout va bien je n'ai
pas fait de modification sur ce daemon et on va le lancer sans se rendre
compte qu'il n'est pas correctement démarré parce qu'une évolution du
logiciel a fait déprécier des options par exemple.
Avec sysvinit, ça fonctionnait un peu différemment: comme le service
plantait avant de forker, start-stop-daemon détectait qu'il plantait et
affichait un message d'erreur. (qui d'ailleurs, ne résulte pas en un
code de retour différent de 0)
La "bonne" solution avec systemd serait probablement que unbound
"prévienne" systemd qu'il s'est correctement initialisé. C'est possible
avec un Type=notify, et systemd-notify / sd_notify.
Mais à part ça, c'est dur de trouver une solution: combien de temps
systemd devrait-il attendre après le lancement d'un service pour
conclure que "c'est bon, il tourne depuis X secondes, on peut dire que
s'il a a pas planté jusque là, il fonctionne vraiment!" ?
Cela met bien en évidence les faiblesses de ce système quand un fork
était plus logique dans le contrôle des processus.
Le timeout va dépendre pas mal du type de logiciel, par exemple une base
de donnée qui doit faire des vérifications au démarrage cela peut
prendre pas mal de temps. De ce point de vue sysvinit avait déjà ses
limites, un timeout existait et j'ai souvent vu des mysql mettre du
temps à démarrer et avoir un retour comme quoi le processus n'était pas
lancé alors qu'il n'avait juste pas fini ses traitements.
L'envoie du signal par l'application, pourquoi pas mais je vois mal
toutes les applications en mode daemon faire des modifications dans ce
sens sachant qu'après tout chacun est libre de choisir son init. Déjà
que la plupart des progiciels en entreprises préconisent un lancement
manuel à chaque démarrage et que depuis tant d'année faire un script
sysvinit cela semble trop compliqué pour eux ... Il va y avoir vraiment
deux mondes, les binaires aptes à communiquer avec systemd et les autres
... ça sera vraiment dommageable.Ensuite réflex je fais un tail de /var/log/syslog pour trouver un
message d'erreur et là rien. J'introduis volontairement une ligne non
conforme dans le fichier de configuration pour voir et là rien aussi,
aucun log dans syslog.
Je suppose que c'est systemd qui a attrapé ces logs mais vu que ce n'est
pas du fichier texte et qu'il faut passer par une commande que j'arrive
pas encore à retenir ...
J'ai fait la même erreur dans le fichier config sur Debian 6 et 7 j'ai
bien mes logs et le script de démarrage me précise bien que le processus
n'a pas démarré.
Alors ça, par contre, ça m'étonne beaucoup. J'ai testé:
J'ai modifié /etc/unbound/unbound.conf pour y ajouter une erreur.
J'ai redémarré unbound (service unbound restart).
Je n'ai pas de message d'erreur à cause du problème ci-dessus.
Mais avec 'service unbound status, qui appelle en fait 'systemctl status
unbound', j'ai bien l'extrait de log:
# service unbound status
● unbound.service - (null)
Loaded: loaded (/etc/init.d/unbound)
Drop-In: /run/systemd/generator/unbound.service.d
└─50-insserv.conf-$named.conf, 50-unbound-$named.conf
Active: active (exited) since Tue 2015-05-12 10:44:36 CEST; 1min 17s ago
Process: 1827 ExecStop=/etc/init.d/unbound stop (code=exited, status=0/SUCCESS)
Process: 1834 ExecStart=/etc/init.d/unbound start (code=exited, status=0/SUCCESS)
May 12 10:44:36 debian unbound-anchor[1843]: /var/lib/unbound/root.key has content
May 12 10:44:36 debian unbound-anchor[1843]: success: the anchor is ok
May 12 10:44:36 debian unbound[1834]: Starting recursive DNS server: unbound/etc/unbound/unbound....qqd'
May 12 10:44:36 debian unbound[1834]: read /etc/unbound/unbound.conf failed: 1 errors in configur...file
May 12 10:44:36 debian unbound[1834]: [1431420276] unbound[1845:0] fatal error: Could not read co...conf
May 12 10:44:36 debian unbound[1834]: failed!
Hint: Some lines were ellipsized, use -l to show in full.
Là ça commence à parler et à prendre forme, mais effectivement faut
changer ses habitudes j'utilise rarement status avec service car tous
les daemons ne l'implémentent pas, cela aurait été tellement plus simple
d'avoir une erreur après le start.
J'ai les mêmes messages avec 'journalctl', et dans /var/log/syslog
Aurais-tu désactivé la redirection vers syslog, par hasard ? (ForwardToSyslog= dans /etc/systemd/journald.conf)
La Debian 8 en question est toute neuve, je vais regarder si
l'installation fournie par le prestataire ne désactive pas des éléments
syslog mais je doute ça serait assez mal venu de faire cela.
Encore merci pour tes explications
Je me permets de répondre car je souhaiterais apporter quelques précisions
sur la raison pour laquelle unbound ici n'affiche pas d'erreur.
Je pense que vous vous fourvoyez sur la façon dont systemd démarre les
services, il n'y a pas de binaire compatible ou non avec systemd, la réalité
c'est qu'un service initialisé avec systemd doit dans l'idéal ne pas forker
lui-même,
et dans le cas présent, unbound n'utilise pas un service systemd
mais le script de sysvinit démarré via systemd.
Le soucis que l'on a avec ce système, c'est que systemd n'a plus de pid du
processus attaché à lui-même, et il ne se contente que d'exécuter le script
qui va forker unbound avec start-stop-daemon unbound.
Pour systemd, le script a bien été exécuté et il a quitté correctement vu
que c'est ce qu'on lui a demandé de faire.
Le problème vient ici du fait que le mainteneur n'a pas fait de fichier
.service conforme pour unbound mais a préféré utiliser le script de sysvinit
au dessus de systemd, ce qui fonctionne dans le meilleur des cas, mais qui
n'est pas correcte.
Je me permets de répondre car je souhaiterais apporter quelques précisions
sur la raison pour laquelle unbound ici n'affiche pas d'erreur.
Je pense que vous vous fourvoyez sur la façon dont systemd démarre les
services, il n'y a pas de binaire compatible ou non avec systemd, la réalité
c'est qu'un service initialisé avec systemd doit dans l'idéal ne pas forker
lui-même,
et dans le cas présent, unbound n'utilise pas un service systemd
mais le script de sysvinit démarré via systemd.
Le soucis que l'on a avec ce système, c'est que systemd n'a plus de pid du
processus attaché à lui-même, et il ne se contente que d'exécuter le script
qui va forker unbound avec start-stop-daemon unbound.
Pour systemd, le script a bien été exécuté et il a quitté correctement vu
que c'est ce qu'on lui a demandé de faire.
Le problème vient ici du fait que le mainteneur n'a pas fait de fichier
.service conforme pour unbound mais a préféré utiliser le script de sysvinit
au dessus de systemd, ce qui fonctionne dans le meilleur des cas, mais qui
n'est pas correcte.
Je me permets de répondre car je souhaiterais apporter quelques précisions
sur la raison pour laquelle unbound ici n'affiche pas d'erreur.
Je pense que vous vous fourvoyez sur la façon dont systemd démarre les
services, il n'y a pas de binaire compatible ou non avec systemd, la réalité
c'est qu'un service initialisé avec systemd doit dans l'idéal ne pas forker
lui-même,
et dans le cas présent, unbound n'utilise pas un service systemd
mais le script de sysvinit démarré via systemd.
Le soucis que l'on a avec ce système, c'est que systemd n'a plus de pid du
processus attaché à lui-même, et il ne se contente que d'exécuter le script
qui va forker unbound avec start-stop-daemon unbound.
Pour systemd, le script a bien été exécuté et il a quitté correctement vu
que c'est ce qu'on lui a demandé de faire.
Le problème vient ici du fait que le mainteneur n'a pas fait de fichier
.service conforme pour unbound mais a préféré utiliser le script de sysvinit
au dessus de systemd, ce qui fonctionne dans le meilleur des cas, mais qui
n'est pas correcte.