démarrer un service à la demande ? Y'avait pas un déjà truc qui s'appelait inetd ?
Je parle justement de inetd dans la dépêche; pour t'éviter de tout lire: oui, inetd le fait pour les sockets Internet; mais n'est pas utilisé dans ce mode (généralement il lance une instance par requête). Il semblerait que certaines implémentations existe pour le faire sur les sockets de type fichier; mais je n'en ai jamais vu. Rien n'existe pour les messages SystemV à ma connaissance, ni sur la présence de fichiers dans un répertoire. systemd propose une solution qui généraliste le démarrage à la demande à un maximum de solutions techniques.
eviter de démarrer 1000 processus ? y'a qu'à utiliser un shell plus complet, comme un bon vieux lisp des familles.
On pourrait utiliser emacs ? Le soucis c'est qu'à nouveau, on sort du normalisé. Les shells plus puissant sont généralement bien plus lourds parce qu'ils ont aussi beaucoup de développements liés à l'interactivité qui n'ont aucun intérêt dans un script.
suivre les processus? J'ai du mal avec ça, mais il y a pas un système de log sous linux?
Si, bien sur; mais je ne connais aucun système qui va rediriger les logs des services. Généralement la tache en est confiée au service.
contrôler le contexte du service ? je ne vois pas ce qui ne pourrait pas être fait sous un shell, avec quelques librairies.
A nouveau, rien n'est impossible; mais il n'existe pas de lanceur de service qui s'occupent à la fois de modifier l'user, les groupes, les cgroups, les capacités, le chroot, les logs, le contexte selinux, les limits, le umask et que sais-je encore. A chaque fois ça passe par l'écriture ou le bidouillage du script de démarrage qui n'a généralement pas été prévu pour. On se retrouve avec 150 scripts très semblables dans /etc/init.d dont aucun n'est complet.
Dans ce sens, systemd permet de passer en chroot un service qui n'avait pas été prévu pour, simplement en modifiant son fichier de configuration.
[^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
Posté par Sébastien Koechlin . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 9.
On reprends:
Je parle justement de inetd dans la dépêche; pour t'éviter de tout lire: oui, inetd le fait pour les sockets Internet; mais n'est pas utilisé dans ce mode (généralement il lance une instance par requête). Il semblerait que certaines implémentations existe pour le faire sur les sockets de type fichier; mais je n'en ai jamais vu. Rien n'existe pour les messages SystemV à ma connaissance, ni sur la présence de fichiers dans un répertoire. systemd propose une solution qui généraliste le démarrage à la demande à un maximum de solutions techniques.
On pourrait utiliser emacs ? Le soucis c'est qu'à nouveau, on sort du normalisé. Les shells plus puissant sont généralement bien plus lourds parce qu'ils ont aussi beaucoup de développements liés à l'interactivité qui n'ont aucun intérêt dans un script.
Si, bien sur; mais je ne connais aucun système qui va rediriger les logs des services. Généralement la tache en est confiée au service.
A nouveau, rien n'est impossible; mais il n'existe pas de lanceur de service qui s'occupent à la fois de modifier l'user, les groupes, les cgroups, les capacités, le chroot, les logs, le contexte selinux, les limits, le umask et que sais-je encore. A chaque fois ça passe par l'écriture ou le bidouillage du script de démarrage qui n'a généralement pas été prévu pour. On se retrouve avec 150 scripts très semblables dans /etc/init.d dont aucun n'est complet.
Dans ce sens, systemd permet de passer en chroot un service qui n'avait pas été prévu pour, simplement en modifiant son fichier de configuration.