• [^] # Re: moi c'est l'inverse

    Posté par . En réponse au journal Linux ne m'intéresse plus. Évalué à 3. Dernière modification le 10 décembre 2020 à 13:25.

    Mais on n'a pas besoin de systemd mais plutôt d'un superviseur et il en existe.

    Pour faire un corollaire, critiquer systemd revient à être accusé d'antivax. Non je ne rejete pas le concept de supervision mais cette implémentation de la supervision.

    OpenBSD a pu faire un truc tout propre qui s'appelle rc.d.

    Je vais citer la conclusion d'Antoine Jacoutot lors de la BSDCAN 2016

    The aim of the rc.d system on OpenBSD is to provide a simple way to control daemons while keeping the original paradigm intact. It is a compromise between features, ease-of-use and simplicity. The addition of rcctl also gave us a unified interface to the rc framework. It is by no mean a complete replacement of the traditional BSD initialization sequence, a process control framework nor a service supervisor.
    While somewhat analogous to a SysV init, we prevented the unmaintainable bloat which in our opinion was its main flaw (how many people really use the non-default runlevels in practice?) and not the fact that it's old and in shell.
    Our rc.d does come with a few obvious deficiencies like not being able to always match a specific daemon when several occurrences are running (due to its process list being too generic, e.g. with a privilege separated daemon: "syslogd: [priv]")... but dealing with these deficiencies would have meant coming up with something much more complex. Handling elaborate applications stacks is often better done on a case by case basis by using external helpers run from rc.local and rc.shutdown rather than bloating the rc.d framework.
    This is mostly due to using only shell code in the framework. That said, regular Bourne shell is easy to read and write and still provides us with a lot of features allowing to replace code instead of adding some.By its nature rc.d may not be suitable for all possible uses but no promises were made that couldn't be kept.

    C'est un premier pas. Il peut être assisté par d'autres composant (supervisord?) etc...

    Mais pas cet immondice de

    systemd-resovld
    systemd-networkd
    systemd-hostnamed
    systemd-homed
    ...