Marrant cette remarque car quand un service ne se lance pas, la 1ere chose que je fais (si je ne vois rien de concret dans les logs) est de farfouiller dans les dizaines de lignes de shell pour sortir la ligne d'appel effective et de lancer moi même la commande pour avoir la sortie std / err : J'ai encore en mémoire un debug de lancement foireux de PostgreSQL, qui était un script shell qui appelle un script shell qui appelle un script Perl (simplicité Debian), ce dernier ayant un bug sur la transmission des options se trouvant dans le fichier de configuration.
Si je ne suis pas spécialement pro-Systemd, mais il a au moins le mérite de remettre sur la table des points douloureux que personne ne voulait régler. Que des gens veulent fonctionner à l'ancienne est compréhensible (pour plein de raisons, bonnes ou mauvaises), mais perso je ne peux plus voir en peinture cet amas de shell.
[^] # Re: Hmm
Posté par Sébastien Douche . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 10.
Marrant cette remarque car quand un service ne se lance pas, la 1ere chose que je fais (si je ne vois rien de concret dans les logs) est de farfouiller dans les dizaines de lignes de shell pour sortir la ligne d'appel effective et de lancer moi même la commande pour avoir la sortie std / err : J'ai encore en mémoire un debug de lancement foireux de PostgreSQL, qui était un script shell qui appelle un script shell qui appelle un script Perl (simplicité Debian), ce dernier ayant un bug sur la transmission des options se trouvant dans le fichier de configuration.
Si je ne suis pas spécialement pro-Systemd, mais il a au moins le mérite de remettre sur la table des points douloureux que personne ne voulait régler. Que des gens veulent fonctionner à l'ancienne est compréhensible (pour plein de raisons, bonnes ou mauvaises), mais perso je ne peux plus voir en peinture cet amas de shell.