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
--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
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/
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/
Il me semble qu'il est recommandé de remplacer la commande `service` par
`systemctl`
Le 10/05/2015 11:38, Wallace a écrit :
--
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/
Le 10/05/2015 14:36, Guillaume a écrit :
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$
--23CGj3hlEI3O2rUGwplok4a19sLCmHITp
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Le 11/05/2015 01:59, Francois Lafont a écrit :
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/
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!" ?
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/
--lfXIALeexWfgMSllhNgfUe3sU6LJg545V
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Le 12/05/2015 10:58, Lucas Nussbaum a écrit :
Merci pour ton retour et tes explications.
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.
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.
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.
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/
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:
--
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/
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.
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/