• [^] # Re: OpenRC

    Posté par . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 4.

    _ openRC conserve la complexité d'écriture de scripts de sysVinit ( j'entends par la que la syntaxe utilisée est celle de sh, ce qui est complexe du point de vue utilisateur, pas de celui du système )

    Une unité systemd c'est ça :

    [Unit]
    Description=Darkhttpd Webserver
    [Service]
    EnvironmentFile=/etc/conf.d/darkhttpd
    ExecStart=/usr/sbin/darkhttpd $DARKHTTPD_ROOT --daemon $DARKHTTPD_OPTS
    Type=forking
    [Install]
    WantedBy=multi-user.target

    Un service OpenRC c'est ça :

    #!/sbin/runscript
    # Copyright 1999-2011 Gentoo Foundation
    # Distributed under the terms of the GNU General Public License v2
    # $Header: /var/cvsroot/gentoo-x86/app-admin/metalog/files/metalog.initd,v 1.5 2011年09月23日 03:15:23 vapier Exp $
    extra_started_commands="buffer unbuffer"
    PIDFILE=/var/run/metalog.pid
    depend() {
     need localmount
     use clock hostname
     after bootmisc
     provide logger
    }
    ssd() { start-stop-daemon --exec /usr/sbin/metalog --pidfile "${PIDFILE}" "$@" ; }
    start() {
     ebegin "Starting metalog"
     ssd --start -- \
     --daemonize --pidfile="${PIDFILE}" ${METALOG_OPTS}
     eend $?
    }
    stop() {
     ebegin "Stopping metalog"
     ssd --stop
     eend $?
    }
    buffer() {
     ebegin "Enabling log buffering"
     ssd --signal USR2
     eend $?
    }
    unbuffer() {
     ebegin "Disabling log buffering"
     ssd --signal USR1
     eend $?
    }

    C'est pas démesuré comme difficulté.

    _ mais openRC permets de paralléliser les tâches ( comme pour systemd ) . Chose qui d'ailleurs m'intrigue vu que j'ai lu diverses allégations laissant supposer que sysVinit en serait aussi capable ( on parle de script shell dans les 2 cas si je ne m'abuse, donc ça ne m'a pas semblé irréaliste )

    La parallélisation est indépendante de la façon de décrire le lancement d'un service. On pourrait très bien réécrire tous les scripts d'init en ruby ça n'empêcherait pas sysvinit (svi) de faire du parallélisme. Il lance les scripts (ou binaires d'ailleurs) en parallèle il se fout de savoir ce qu'il y a derrière (ça c'est pour OpenRC et svi).

    Ensuite ce qui démarque systemd de ces deux là c'est que le modèle de parallélisme n'est pas le même.

    Dans OpenRC et svi tu construit un arbre de dépendances de manière statique. Tu indique pour chaque service de quel services il dépend et l'init va se débrouiller pour lancer le services dont toutes les dépendances sont satisfaites en même temps. svi parle d'un make style pour décrire la manière dont il fait l'exécution.

    Dans systemd, tu peut décrire ce genre de dépendance, mais ce n'est pas forcément nécessaire, il est capable de détecter tout seul les dépendances. Par exemple si un service A dépend d'un autre (B) et en a besoin parce qu'il communique avec lui par une socket. systemd va lancer A puis lorsque A va avoir besoin de B, il va lancer B (c'est le socket activation). L'avantage de cette méthode c'est qu'elle est dynamique (si A n'avait pas eu besoin de B avant 10 minutes, alors B n'aurait pas était lancé trop tôt).

    C'est bien une différence de paradigme, ils n'ont pas le même modèle d'exécution.

    Si tu veux plus t'informer, je te conseil les dépêches Petit état de l'art des systèmes d'initialisation et Évolutions techniques de systemd.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)