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
Attachment:
signature.asc
Description: OpenPGP digital signature