Jessie et habitude vis à vis de systemd

Le
Wallace
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ef7aLDJMb40nCK941PmoJ4gCNSfEQq2tH
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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 rappo=
rt à
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 ve=
ux 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 p=
ourrait 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'unboun=
d 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 lig=
ne qui
m'aurait dit erreur au démarrage, là rien et pire le code retou=
r 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 no=
n
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èm=
e 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 typi=
que
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 command=
e comme avant
- pouvoir désactiver le catch des logs de systemd et laisser le daem=
on
loguer en syslog comme avant

Merci pour votre aide.

-


--ef7aLDJMb40nCK941PmoJ4gCNSfEQq2tH
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--BEGIN PGP SIGNATURE--
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: GPGTools - http://gpgtools.org
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlVPJxwACgkQFq2gi4VPTl2cOwCdGf102tju8kctf8Xq9Jfqgw+Q
XIoAnijGbLHCtB2c8Ro6QjN5LcFrw1vo
=w9Jf
--END PGP SIGNATURE--

--ef7aLDJMb40nCK941PmoJ4gCNSfEQq2tH--

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/554F2718.9080002@morkitu.org
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Txo
Le #26352009
Le 10/05/2015 11:38, Wallace a écrit :
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 ...



Systemd décline toute responsabilité pour perte de mémoire de
l'utilisateur et pour l'assassinat de Henri IV…

--
-- Dominique Marin http://txodom.free.fr --
«N'oubliez jamais que ce qu'il y a d'encombrant dans la morale
c'est que c'est toujours la morale des autres.»
-- Léo Ferré --

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
maderios
Le #26352013
On 05/10/2015 11:38 AM, Wallace wrote:

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
Ces questions ont déjà été amplement traitées et résolues sur cette
liste (et ailleurs) il y a moins d'un mois. C'est donc disponible dans
les archives de la liste.
--
Maderios

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Guillaume
Le #26352027
Bonjour,

Il me semble qu'il est recommandé de remplacer la commande `service` par
`systemctl`

Le 10/05/2015 11:38, Wallace a écrit :
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.

-





--
Guillaume

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Francois Lafont
Le #26352170
Bonsoir,

Le 10/05/2015 14:36, Guillaume a écrit :

Il me semble qu'il est recommandé de remplacer la commande `service` 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 utilisait
en backend la bonne commande en fonction du système init et que justement
c'était très bien comme ça car on n'avait pas à s'embê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.

--
François Lafont

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/miordr$oid$
Wallace
Le #26352200
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--23CGj3hlEI3O2rUGwplok4a19sLCmHITp
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



Le 11/05/2015 01:59, Francois Lafont a écrit :
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.



Je confirme "service" est bien un wrapper qui sait piloter le bon init
derrière.


--23CGj3hlEI3O2rUGwplok4a19sLCmHITp
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: GPGTools - http://gpgtools.org
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlVQYWwACgkQFq2gi4VPTl2bXQCeIhtPguFsH5Q9Zn8NMj7r7XJ7
OI4An1rK+7a+wm3qUrIZ5GvCvJZ5g+ji
=/EPE
-----END PGP SIGNATURE-----

--23CGj3hlEI3O2rUGwplok4a19sLCmHITp--

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Lucas Nussbaum
Le #26352433
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 ...



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 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!" ?

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.

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)

Lucas

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Wallace
Le #26352434
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--lfXIALeexWfgMSllhNgfUe3sU6LJg545V
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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




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 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!" ?


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 ce la 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 lancemen t
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 vraim ent
deux mondes, les binaires aptes à communiquer avec systemd et les au tres
... ç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 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.



Là ça commence à parler et à prendre forme, mais effe ctivement faut
changer ses habitudes j'utilise rarement status avec service car tous
les daemons ne l'implémentent pas, cela aurait été telleme nt 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




--lfXIALeexWfgMSllhNgfUe3sU6LJg545V
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: GPGTools - http://gpgtools.org
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlVRxU8ACgkQFq2gi4VPTl1gEACfSJqu6yk5LGuDjSdNof2d/KeE
t70An2TBspiHbhtn3BXCRhzKkD6fF5+T
=wkac
-----END PGP SIGNATURE-----

--lfXIALeexWfgMSllhNgfUe3sU6LJg545V--

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Christophe Mehay
Le #26352535
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.


On 12/05/2015 11:18, Wallace wrote:
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






--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Lucas Nussbaum
Le #26352555
On 12/05/15 at 21:50 +0200, Christophe Mehay wrote:
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,



Non, systemd supporte les deux cas (fork avec Type=forking, pas de fork
avec Type=simple). La motivation forte pour ne pas forker, c'est que ce
n'est pas forcément utile, donc autant ne pas le faire. Mais on a vu
dans cette discussion qu'utiliser Type=forking fournissait une manière
peu chère de signaler qu'une partie de l'initialisation du service
s'était bien passée, notamment pour détecter des problèmes de
configuration.

Mais c'est loin d'être parfait: le service pourrait très bien lire sa
config après avoir forké. Et il y a des opérations d'initialisation qui
sont souvent faites après le fork, par exemple ouvrir le port réseau du
service. S'il y a un autre service qui écoute sur le port, ça serait
alors non détecté.

Du coup, la vraie solution, c'est utiliser /socket activation/, ou
Type=notify, pour que le service soit vraiment opérationnel à la fin de
son démarrage.

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.



Oui et non. Pour utiliser les scripts sysv, systemd génère à la volée
des fichiers .service englobant le script d'init (visible avec systemctl
cat unbound). Et il le fait plutôt bien (gestion des en-têtes LSB, des
dépendances, etc, cf
http://www.freedesktop.org/software/systemd/man/systemd-sysv-generator.html).

Utiliser un fichier .service ne réglerait vraiment le problème que si le
service n'utilise pas Type=simple, mais ce n'est pas forcément simple ;)
Voir une discussion sur le cas de sshd (qui utilise type=simple, ce qui
empêche de détecter au lancement des erreurs de configuration):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bugw8913#30

Lucas

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Publicité
Poster une réponse
Anonyme