Ouais, génial. Donc il faut changer d'init,
Parcequ'avec systemd on ne change pas d'init j'imagine...
ou au moins avoir plusieurs outils pour tenter de savoir si un service est démarré ou non (pratique...).
On peut aussi avoir un admin système compétent à la place. Le fait que Debian prévoit plusieurs scénarios pour lancer sshd ne veut pas dire que tu es obligé de tous les garder. Si tu as besoin de 50 outils pour savoir si oui ou non un service est lancé c'est un soucis à voir avec ton admin système, SysV init n'y est pour rien. Et puis très honnêtement si tu es en mode rescue, mono utilisateur, mono console tu es supposé t'en rendre compte. Si /usr ne s'est pas monté et que seuls les services primaires compilés en statique tournent, tu es supposé le voir aussi assez rapidement. Donc bon le mec qui se demande si par hasard sshd ne se serait pas lancé via un des autres scripts, il est supposé avoir une excellente raison de le faire.
En ce qui concerne ta longue citation, c'est l'opinion du monsieur. J'ai exactement l'opinion inverse. Je suis très content avec un système d'init qui en fait le minimum et qui me laisse le champs libre pour choisir ce que je veux pour faire le reste. Je peux prendre les outils de monitoring que je veux, utiliser les cgroups comme bon me semble, décider seul des mécanismes de respawn etc.
Le problème de la daemonisation a déjà été évoqué. Ca n'a rien à avoir avec SysV init, daemoniser un processus c'est complexe quel que soit la raison pour laquelle on a besoin de le faire. SysV init demande juste à ce qu'on lui rende la main - il se moque complètement de savoir comment. Dire que pour être compatible avec SysV init un processus doit passer par les quinze étapes de la daemonisation est juste faux.
En ce qui concerne les ports, c'est une des façons de faire, il y en a d'autres. Par exemple, aucun de mes services n'a jamais les droit root à part ssh, du coup je n'ai jamais à dropper de privilèges. Si un service a besoin d'un port privilégié par exemple, ben il ouvre un port non privilégié sur une interface interne et ce sont des règles firewall qui font le mapping.
Pour finir avec les logs, oui les logs sont une fonctionnalité que chaque service doit ré-implémenter. Mais là je suis curieux de savoir comment faire autrement. Le monsieur a une machine qui permet de déterminer la pertinence d'une info interne à une appli et de la remonter toute seule vers les logs ? Parceque sinon ca va rester le boulot du dev de l'appli de gérer les logs. Quant aux metadatas infalsifiables ajoutés par journald, il y a des fois ou c'est juste pénible. (par exemple un routeur téléphonique de petit opérateur va générer environ 1000 lignes de logs par secondes - logs que l'on est légalement obligé de conserver). On est parti pour 15-20ko/s d'I/O, de bande passante et d'espace disque gaspillé chaque seconde par routeur.
Tout ça pour dire ce sont des points de vue, je les comprend mais j'ai des problématiques et des besoins différents qui font qu'à aujourd'hui systemd ne peut pas me servir.
[^] # Re: C'est là tout le problème
Posté par Kaane . En réponse au journal systemd: je me lance. Évalué à 6.
Ouais, génial. Donc il faut changer d'init,
Parcequ'avec systemd on ne change pas d'init j'imagine...
ou au moins avoir plusieurs outils pour tenter de savoir si un service est démarré ou non (pratique...).
On peut aussi avoir un admin système compétent à la place. Le fait que Debian prévoit plusieurs scénarios pour lancer sshd ne veut pas dire que tu es obligé de tous les garder. Si tu as besoin de 50 outils pour savoir si oui ou non un service est lancé c'est un soucis à voir avec ton admin système, SysV init n'y est pour rien. Et puis très honnêtement si tu es en mode rescue, mono utilisateur, mono console tu es supposé t'en rendre compte. Si /usr ne s'est pas monté et que seuls les services primaires compilés en statique tournent, tu es supposé le voir aussi assez rapidement. Donc bon le mec qui se demande si par hasard sshd ne se serait pas lancé via un des autres scripts, il est supposé avoir une excellente raison de le faire.
En ce qui concerne ta longue citation, c'est l'opinion du monsieur. J'ai exactement l'opinion inverse. Je suis très content avec un système d'init qui en fait le minimum et qui me laisse le champs libre pour choisir ce que je veux pour faire le reste. Je peux prendre les outils de monitoring que je veux, utiliser les cgroups comme bon me semble, décider seul des mécanismes de respawn etc.
Le problème de la daemonisation a déjà été évoqué. Ca n'a rien à avoir avec SysV init, daemoniser un processus c'est complexe quel que soit la raison pour laquelle on a besoin de le faire. SysV init demande juste à ce qu'on lui rende la main - il se moque complètement de savoir comment. Dire que pour être compatible avec SysV init un processus doit passer par les quinze étapes de la daemonisation est juste faux.
En ce qui concerne les ports, c'est une des façons de faire, il y en a d'autres. Par exemple, aucun de mes services n'a jamais les droit root à part ssh, du coup je n'ai jamais à dropper de privilèges. Si un service a besoin d'un port privilégié par exemple, ben il ouvre un port non privilégié sur une interface interne et ce sont des règles firewall qui font le mapping.
Pour finir avec les logs, oui les logs sont une fonctionnalité que chaque service doit ré-implémenter. Mais là je suis curieux de savoir comment faire autrement. Le monsieur a une machine qui permet de déterminer la pertinence d'une info interne à une appli et de la remonter toute seule vers les logs ? Parceque sinon ca va rester le boulot du dev de l'appli de gérer les logs. Quant aux metadatas infalsifiables ajoutés par journald, il y a des fois ou c'est juste pénible. (par exemple un routeur téléphonique de petit opérateur va générer environ 1000 lignes de logs par secondes - logs que l'on est légalement obligé de conserver). On est parti pour 15-20ko/s d'I/O, de bande passante et d'espace disque gaspillé chaque seconde par routeur.
Tout ça pour dire ce sont des points de vue, je les comprend mais j'ai des problématiques et des besoins différents qui font qu'à aujourd'hui systemd ne peut pas me servir.