Petit état de l'art des systèmes d'initialisation (1)

Posté par  (site web personnel) . Édité par Jarvis, Jiehong, needs, ZeroHeure, Nils Ratusznik, Fopossum, Brndan, Benoît Sibaud, Joël Thieffry, Ignatz Ledebur, Storm, talou, reno, etenil, Sylvain Blandel, lenod, claudex et Misc. Modéré par claudex. Licence CC By‑SA.
Étiquettes :
60
3
déc.
2013
Technologie

Ces dernier temps, la question de l'initialisation du système d'exploitation a été au cœur des trolls discussions. Nous allons faire un point sur les différentes approches mise en œuvre possédant une implémentation libre.

Dans cette première partie, nous allons voir arbitrairement quatre systèmes d'initialisation : OpenRC, rcNG, Upstart et runit.

Nous n'aborderons pas systemd du fait qu'il a déjà été évoqué dans de nombreux contenus (ici, ici et là par exemple).

Note : merci à Jarvis Jiehong, needs, Fopossum, Brndan, Joël Thieffry, Storm, MrSpackMan, Nils Ratusznik, Misc, reno, Sylvain Blandel, Benoît Sibaud, lenod,talou, etenil, qui sont les véritables auteurs de cette dépêche.

Sommaire

OpenRC

Présentation

OpenRC est un système d'initialisation du système lancé au moment du début du port Gentoo/FreeBSD. Il cherche à être indépendant du système sous-jacent. Il s'adapte à diverses implémentation d'init. Le précédent système d'initialisation de Gentoo s'appuyait massivement sur des script bash. Lors de l'initialisation du port Gentoo/FreeBSD il est devenu indispensable d'utiliser une solution plus portable : c'est dans cette optique que Roy Marples a lancé le développement d'OpenRC.

OpenRC, bien qu'utilisant sysinit sous Gentoo par exemple, s'affranchit des niveaux d'exécutions (runlevels) habituels en introduisant la notion de niveaux d'exécutions nommés. Ainsi, lors du démarrage du système, on passera du niveau boot au niveau default.

Les principaux avantages d'OpenRC sont sa rapidité, sa gestion des dépendances entre services, et la possibilité de paralléliser (dans une certaine mesure) le démarrage des services.

On trouve par défaut, sur une installation OpenRC, les niveaux d'exécution suivants : boot, default, shutdown et sysinit. Dans ces répertoires se trouvent des liens symboliques pointant vers /etc/init.d où se trouvent effectivement les scripts d'init. Le binaire /sbin/rc est au centre du système. Il est généralement invoqué via le script /etc/rc.

Anatomie d'un script d'init OpenRC

Nous allons prendre l'exemple de metalog, un des gestionnaires de journaux (system loggers) disponible sous Gentoo.

#!/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 $?
}

Les cibles par défaut des scripts sont start, stop et restart.

Ce script est un bon exemple de la versatilité d'OpenRC puisqu'il définit deux nouvelles cibles buffer et unbuffer. Bien que la cible restart ne soit pas définie, elle existe tout de même.

La partie depend liste tous les services nécessaires au bon fonctionnement du programme. On voit dans ce cas que metalog n'a pas besoin du réseau pour démarrer (il y aurait un need net déclaré sinon), et il fournira au système le service logger nécessaire au lancement d'autres services.

Configuration

La configuration des services lancés par OpenRC est relativement simple et se fait par l'intermédiaire des fichiers de configuration portant le nom du service se trouvant dans le répertoire /etc/conf.d et du fichier global /etc/rc.conf.

Comportement global

La configuration d'OpenRC est regroupée dans le fichier /etc/rc.conf. Très abondamment commenté, il permet par exemple de définir si le boot doit être interactif ou parallélisé.

Paramétrage d'un service

Pour paramétrer un service, il doit y avoir une entrée correspondante dans le répertoire /etc/conf.d. Les fichiers présents dans ce répertoire servent à passer des arguments supplémentaires aux démons. Ils sont toujours abondamment commentés et simples à comprendre.

Si nous reprenons notre exemple de metalog, le fichier correspondant dans /etc/conf.d est le suivant :

# /etc/conf.d/metalog
# $Header: /var/cvsroot/gentoo-x86/app-admin/metalog/files/metalog.confd,v 1.7 2006/02/08 01:04:02 vapier Exp $

# Some useful options:
#  -a   Log with buffering
#  -s   Log without buffering
# See `metalog --help` for more

METALOG_OPTS=""


# Options used by /usr/sbin/consolelog.sh

# Space delimited list of devices to write "console" messages to
#CONSOLE="/dev/console /dev/tty10"
CONSOLE="/dev/tty10"

# Format of logging (make sure you use single quotes)
FORMAT='$1 [$2] $3'

Avantages et inconvénients

OpenRC est portable. Il est utilisé sous Gentoo par défaut et peut être utilisé sous FreeBSD et NetBSD sans difficulté.

L'utilisation des niveaux d'exécution nommés permet d'en créer des spécifiques très facilement. On peut, pour un ordinateur portable par exemple, créer un niveau d'exécution nommé « battery » et indiquer au système, via un événement ACPI, de passer à ce niveau d'exécution lorsque le portable fonctionne sur batterie. Nous pouvons ainsi arrêter des services précis pour économiser de l'énergie.

C'est en couleurs ! On voit très vite quand il y a du rouge dans le démarrage ! Et le rouge, c'est mal.

Après 5 ans de développement, il était tout de même utilisé quotidiennement par des milliers d'utilisateurs en ~arch (la version de test de Gentoo) sans aucun problème.

Depuis la version 0.11.8 (disponible dans l'arbre portage depuis le 7 décembre 2012) OpenRC est considéré comme stable et peut donc être utilisé par tous les gentooistes sans risque de casser entièrement son système de démarrage. La lecture du guide de migration en anglais reste néanmoins une bonne source d'information pour bien comprendre les différences entre le baselayout-1 et le baselayout-2 et les modifications éventuelles à apporter à son système pour profiter pleinement des capacités de ce système d'initialisation.

Il est à noter que les versions 0.12 et supérieures (toujours en ~arch) disposent du support des CGroups. De nombreuses fonctionnalités d'OpenRC sont décrites sur le wiki officiel Gentoo dans la catégorie OpenRC. Dernier inconvénient, les scripts d'init doivent être ré-écrits pour OpenRC : en effet, il n'utilise pas ceux disponibles pour les autres distributions plus « traditionnelles ».

Cependant, peu de distributions se sont penchées dessus.

rcNG

On parle ici de l'init sous NetBSD, FreeBSD et DragonFlyBSD. Le principe de base est classique :

  • un init simple et robuste ;
  • du shell bourne (évolution d'ash).

Initialisation

init est lancé par défaut après le chargement du noyau. Il initialise les terminaux, gère les journaux de session et l'état du système. Il est configuré par /etc/ttys qui détermine la nature des différents terminaux. C'est un automate à état fini qui essaye de remplir plusieurs objectifs comme on peut le lire dans les notes d'implémentation :

  1. Un traitement fasciste des signaux. Y compris ceux émanant du matériel :
    • SIGSYS (appel système inexistant) est suspect, on appelle la routine qui détermine si le problème se produit souvent avant, éventuellement, de déclencher le désastre ;
    • SIGABRT, SIGFPE, SIGILL, SIGSEGV, SIGBUS, SIGXCPU, SIGXFSZ dénotent les erreurs irrécupérables et conduisent irrémédiablement au désastre ;
    • SIGHUP, SIGINT, SIGTERM, SIGTSTP, SIGUSR1, SIGUSR2 permettent à l'utilisateur de déclencher un changement d'état.
  2. Une prise en charge élégante des erreurs fatales en essayant, par exemple, d'envoyer un message sur la console et d'attendre un peu avant de redémarrer.
  3. Une prise en charge des fils la moins coûteuse possible :
    • ne pas surveiller un processus endormi ;
    • ne pas utiliser SIGCHILD, jugé trop coûteux ;
    • appliquer une heuristique pour quitter rapidement getty ;
    • gérer les appels systèmes interrompus (EINTR) en cas de changement de transition.

L'automate lui même est défini ainsi :

  1. mode mono-utilisateur ; en sortant, passer à 2 ;
  2. lancement du mode multi-utilisateurs ; en sortant, aller à 3 ; retourner à 1 si erreur ;
  3. lecture du fichier ttys(5) ; en sortant, aller à 4 ;
  4. mode multi-utilisateurs ; aller en 5, 6 ou 7 suivant le signal envoyé ;
  5. mode nettoyage (relecture du fichier tty(5) et application des modifications) ; aller en 4 ;
  6. mode ennuyeux (système verrouillé : pas de nouvelles sessions) ; aller en 5 ou 7 suivant le signal reçu ;
  7. mort ; signaler tous les fils (SIGHUP originel : raccrocher), attendre 30 secondes et aller en 1.

Lancement des services

Ce qui nous intéressera particulièrement est la transition 2. Celle-ci lance l’exécution du script /etc/rc.

Rc, dit NG, est le système mis en œuvre par NetBSD puis FreeBSD. Il est également à l'origine du système utilisé jusqu'à très récemment par ArchLinux. Il se situe historiquement dans la lignée des init dits BSD. Mais il remplace avantageusement les scripts historiques /etc/rc.service par quelque chose du plus souple et de facile à configurer.

Il va lancer dans le bon ordre les différentes tâches nécessaires au démarrage du mode multi-utilisateur. Chaque tâche correspond à un script dans le répertoire /etc/rc.d qui effectue en principe une tâche simple (en moyenne 64 lignes par script, commentaires compris). Les scripts trop complexes tendent à être éliminés au profit d'autres solutions. Par exemple la commande jail qui lance les conteneurs de même nom a été réécrite. Cela permettra de remplacer plus de 700 lignes du script de rc par un simple jail -c.

L'ordre de lancement est évalué en fonction des mots clés PROVIDE, REQUIRE et BEFORE présents dans les scripts. Chaque script est ainsi sourcé dans l'ordre. Le fichier /etc/default/rc.conf, fournit la configuration par défaut sous la forme variable=valeur qui peut être surchargée dans le fichier /etc/rc.conf.

Exemple de script de rc :

# PROVIDE: syslogd
# REQUIRE: mountcritremote cleanvar newsyslog
# BEFORE:  SERVERS

. /etc/rc.subr

name="syslogd"
rcvar="syslogd_enable"
pidfile="/var/run/syslog.pid"
command="/usr/sbin/${name}"
required_files="/etc/syslog.conf"
start_precmd="syslogd_precmd"
extra_commands="reload"

sockfile="/var/run/syslogd.sockets"
evalargs="rc_flags=\"set_socketlist \$rc_flags\""
altlog_proglist="named"

syslogd_precmd()
{
    local _l _ldir

    #   Transitional symlink for old binaries
    #
    if [ ! -L /dev/log ]; then
        ln -sf /var/run/log /dev/log
    fi
    rm -f /var/run/log

    #   Create default list of syslog sockets to watch
    #
    ( umask 022 ; > $sockfile )

    #   If running named(8) or ntpd(8) chrooted, added appropriate
    #   syslog socket to list of sockets to watch.
    #
    for _l in $altlog_proglist; do
        eval _ldir=\$${_l}_chrootdir
        if checkyesno ${_l}_enable && [ -n "$_ldir" ]; then
            echo "${_ldir}/var/run/log" >> $sockfile
        fi
    done

    #   If other sockets have been provided, change run_rc_command()'s
    #   internal copy of $syslogd_flags to force use of specific
    #   syslogd sockets.
    #
    if [ -s $sockfile ]; then
        echo "/var/run/log" >> $sockfile
        eval $evalargs
    fi

    return 0
}

set_socketlist()
{
    local _s _socketargs

    _socketargs=
    for _s in `cat $sockfile | tr '\n' ' '` ; do
        _socketargs="-l $_s $_socketargs"
    done
    echo $_socketargs
}
load_rc_config $name
run_rc_command "$1"

Une fois son travail terminé, rc rend la main à init qui ouvre les terminaux. Le système est lancé. init n'a plus alors qu'à attendre la prochaine ouverture de session ou la prochaine transition. Les services peuvent être gérés en utilisant le script /etc/rc.d/_XXX_ [one|force]start|stop|status|restart ou via l’utilitaire service(8). Au moment de l’arrêt c'est le script /etc/rc.shutdown qui est invoqué.

Upstart

Présentation

Upstart est un système d'initialisation créé en 2006 par Scott James Remnant, employé alors chez Canonical. Bien que son développeur principal soit parti de Canonical, il est encore en développement. Il est écrit en C en utilisant la bibliothèque NIH Utility Library. La dernière version (1.10) est parue le 23 août.

Upstart gère le démarrage et l'arrêt des services en fonction d'événements. Il doit donc gérer un arbre de dépendances qui permet de définir à l'avance le comportement d'un service en fonction d'un événement.

Utilisation

La commande principale est initctl :

initctl status udev
udev start/running, process 330

Rien de bien nouveau au niveau des actions sur les services :

  • start : démarrer le service ;
  • stop : arrêter le service ;
  • restart : relancer le service ;
  • reload : recharger le service ;
  • status : connaître l'état du service.

La commande permet d'avoir d'autres renseignements. Par exemple, pour lister les différents services :

initctl list
[...]
udev start/running, process 330
[...]
  • udev : nom du service ;
  • start/running : l'état ;
  • process 330 : pid du processus lié au service.

Anatomie d'un script d'init Upstart

Les fichiers de configuration se trouve dans le répertoire : /etc/init/.

Exemple de configuration :

cat /etc/init/udev.conf
# udev - device node and kernel event manager
#
# The udev daemon receives events from the kernel about changes in the
# /sys filesystem and manages the /dev filesystem.

description "device node and kernel event manager"

start on virtual-filesystems
stop on runlevel [06]

expect fork
respawn

exec /sbin/udevd --daemon
  • start on : quand faut-il démarrer le service ?
  • stop on : quand faut-il stopper le service (ici : runlevel 0 ou 6) ?
  • expect fork : le processus s'attend à avoir une seule fois un fork (voir ici) ;
  • respawn : permet de démarrer le service si celui-ci a été stoppé pour certaine raison (voir ici) ;
  • exec : la commande à lancer.

Comme on peut le constater dans la documentation, il est possible de configurer un script de façon importante.

Avantages et inconvénients

Il est (ou a été) utilisé par défaut par de nombreuses distributions : Ubuntu, Red Hat Entreprise Linux, Fedora et Chrome OS. Ce qui démontre une bonne stabilité. Il est encore en développement, il essaie de rattraper le retard par rapport à systemd : logind, cgroups, …

runit

Présent sur Debian comme système de démarrage alternatif, runit est un remplaçant multiplate-forme de sysVinit, il se veut aussi simple et minimal que possible. Le développement de l'implémentation initiale n'est plus actif depuis fin 2009, mais il en existe une autre, introduite dans Busybox 1.3.0 et toujours maintenue.

Il permet de paralléliser (dans une certaine mesure) le démarrage, de définir des niveaux d'exécution nommés et de superviser les services.

Fonctionnement

Le fonctionnement de runit est plutôt simple :

  • stage 1 (initialisation) : toutes les tâches d'initialisations du système sont effectuées ici, elles sont décrites dans /etc/runit/1 ; si l'une d'elles échoue, runit est capable de démarrer un shell d'urgence, sinon il lance le stage 2 ;
  • stage 2 (stage principal) : lance et gère toutes les tâches de /etc/runit/2 ; celui-ci prend fin uniquement lors de l'extinction ou du redémarrage, il laissera alors la main au stage 3 ;
  • stage 3 (extinction/redémarrage) : termine le stage 2 si celui-ci tourne encore, et effectue toutes les tâches d'extinction ou de redémarrage.

Services

Runit agit aussi comme gestionnaire de services et permet de gérer les démons grâce au programme sv. Ce dernier s'utilise de la manière suivante (pour plus de commandes voir la page de manuel sv(8)) :
sv [start|stop|status|restart] service.

Pour gérer ces services, deux répertoires sont utilisés :

  • /etc/sv/ qui contient un dossier pour chaque service, contenant un script bash run, qui se charge de lancer le service, et un sous-dossier log/ contenant lui aussi un script bash run qui lance cette fois-ci le programme d'écriture des journaux ;
  • /etc/service/ : c'est ici que l'on active/désactive un service ; ce répertoire ne contient que des liens symboliques, la commande typique pour activer un service est la suivante : ln -s /etc/sv/git-daemon/ /etc/service/.

Une fois le service créé et activé, on peut utiliser sv pour le gérer. Ci-dessous, un exemple assez simple mais amplement suffisant.

Exemple de service : git-daemon

Le fichier /etc/sv/git-daemon/run :

#!/bin/bash
exec 2>&1
echo 'git-daemon starting.'
exec chpst -ugitdaemon:git \
  "$(git --exec-path)"/git-daemon --verbose --reuseaddr \
    --base-path=/home/git/repositories /home/git/repositories

Vous noterez que chpst est un outil de runit permettant de changer l'état d'un processus. Ici on l'utilise pour changer le groupe et l'utilisateur sous lequel va tourner le service.

Le fichier /etc/sv/git-daemon/log/run :

#!/bin/bash
set -e

LOG=/var/log/git-daemon

test -d "$LOG" || mkdir -p -m2750 "$LOG" && chown gitlog:adm "$LOG"
exec chpst -ugitlog svlogd -tt "$LOG"

Vous noterez également que svlogd est aussi fourni par runit qui le définit comme le gestionnaire de journaux privilégié.

Et pour le lancer : sv start git-daemon !

Journaux

Si svlogd est utilisé, on peut alors consulter les fichiers journaux dans le dossier suivant : /var/log/git-daemon/ (dans le cas de notre exemple vu ci-dessus, sinon remplacer 'git-daemon' par le nom de votre service). Dans ce dossier, on trouve les fichiers suivant :

  • current : contient les derniers logs enregistrés par le service ; un moyen simple de les lire est d'utiliser la commande tail, par exemple : tail -f /var/log/git-daemon/current ;
  • des fichiers nommés de la sorte : @ + horodate (timestamp) + .s ; lorsque current devient trop gros, svlogd le renomme selon la dernière horodate enregistrée, et crée un nouveau fichier current : c'est la rotation des fichiers journaux.

Pour gérer le format des journaux, ou pour toute autre tâche liée aux journaux, la page du manuel svlogd(8) devrait vous combler.

  • # SMF ?

    Posté par  . Évalué à 6.

    Bonjour,

    Pour compléter la liste, il y a aussi les Service Management Facility (SMF) développés par Sun Oracle dont une implémentation libre existe dans OpenSolaris OpenIndiana.

    La page dédiée de leur wiki donne quelques exemples, mais en gros, c'est du XML, ça gère les dépendances et l'auto restart en cas de crash…

  • # Précision: rcNG et DragonFly

    Posté par  (site web personnel) . Évalué à 5.

    Les services peuvent être gérés en utilisant le script /etc/rc.d/_XXX_ [one|force]start|stop|status|restart ou via l’utilitaire service(8).

    Chez DragonFly BSD, l'utilitaire rcrun(8) est utilisé et non pas service(8).

  • # État des services une fois le système démarré

    Posté par  (site web personnel) . Évalué à 4.

    Est-ce que les connaisseurs de chaque système d'initialisation pourraient indiquer comment est-ce que l'on fait pour savoir, une fois le système complètement démarré, quels services ont échoué lors du démarrage et quels services sont effectivement lancés ?

    Merci

  • # systemd

    Posté par  . Évalué à 2.

    J’avoue, j’ai carrément sourit en lisant le titre. Je suis grave je crois. Mais bref. J’ai été assez déçu d’apprendre qu’on y parlait pas de systemd. :( Ça aurait pu faire de beaux trolls!

    Blague à part, c’est pas mal d’entendre parler des autres systèmes d’initialisation. Passons aux choses sérieuses:

    OpenRC

    Je reprends un bout de code de la dépêche:

    ssd() { start-stop-daemon --exec /usr/sbin/metalog --pidfile "${PIDFILE}" "$@" ; }

start() {
        ebegin "Starting metalog"
        ssd --start -- \
            --daemonize --pidfile="${PIDFILE}" ${METALOG_OPTS}
        eend $?
}

    Mais la syntaxe m’a l’air un tantinet plus chiant que ce que ça pourrait être.

    • Pourquoi ebegin? C’est pas le genre de trucs qui pourrait se faire automatiquement? Dans d’autres cas comme la fonction buffer() je comprends, mais là?
    • À quoi sert eend $?? On dirait qu’on le systématiquement donc je vois pas l’intérêt.
    • À quoi sert la fonction ssd()?

    Il semble flexible et j’en ai entendu pas mal de bien, ça a l’air d’être le système le plus cité pour remplacer un système d’initialisation vieillissant pour ceux qui veulent éviter systemd à tout prix.

    rcNG

    Rho le gros pâté de shell… Bah c’est pas très beau, mais bon faudrait une vraie comparaison (même démon et code équivalent).

    Ça a l’air de garder un fonctionnement assez traditionnel.

    Upstart

    Fichier décrivant le démon très succin, ça fait assez penser à systemd (même si carrément pas la même syntaxe).

    Concernant le logiciel en lui-même, bah c’est du systemd en moins bon quoi.

    runit

    Syntaxe pour les fichiers décrivant les démons pas très belle, séparé le tout en plein de petits fichiers c’est pas un peu chiant?

    Vu la description, ça a pas l’air très flexible. Est-il possible de créer son propre niveau d’exécution? (runlevel)

    Conclusion

    Globalement ça a pas l’air de paralléliser autant que systemd, et les syntaxes basés sur le Shell sont à mon avis une horreur.

    Enfin bref, quand je vois les autres système d’initialisation, je pense que systemd n’a pas trop de soucis à se faire, puisqu’ils ne jouent clairement pas dans la même catégorie (à part Upstart). OpenRC, rcNG et runit se veulent multiplateforme, ce qui n’est pas le cas de systemd.

    Est-ce que quelqu’un a déjà jeté un œil aux performances pour voir ce que ça donnait?

    Écrit en Bépo selon l’orthographe de 1990

    • [^] # Re: systemd

      Posté par  . Évalué à 4.

      j’avoue, j’ai carrément sourit en lisant le titre. Je suis grave je crois. Mais bref. J’ai été assez déçu d’apprendre qu’on y parlait pas de systemd. :( Ça aurait pu faire de beaux trolls!

      Ben justement, non, c'est fatiguant.
      On ne sait toujours pas où en Systemd et si son apport est sensible ou non.
      Comme dit dans un commentaire plus haut, SMF aurait eu sa place également et j'aurais aimé qu'on l'on compare les autres solutions à celu- ci, car SMF c'est super robuste et complet: état détaillé, gestion des dépendances, monitoring. Par contre Il n'est pas des plus rapides.

    • [^] # Re: systemd

      Posté par  . Évalué à 10. Dernière modification le 03 décembre 2013 à 22:35.

      Mais la syntaxe m’a l’air un tantinet plus chiant que ce que ça pourrait être.

      • Pourquoi ebegin? C’est pas le genre de trucs qui pourrait se faire automatiquement? Dans d’autres cas comme la fonction buffer() je comprends, mais là?

      ebengin affiche le log en début de ligne.

      • À quoi sert eend $?? On dirait qu’on le systématiquement donc je vois pas l’intérêt.

      eend est appelé après le démarage du démon. Il récupère le code de retour avec $?. Si c’est bon, il écrit un beau ok vert à droite de l’écran, si c’est ko c’est écrit en rouge.

      • À quoi sert la fonction ssd()?

      Ça appelle la fonction définie au dessus, ce qui permet d’éviter d’appeler dans les fonctions start, stop, buffered, unbuffered les nombreux paramètres de ssh, en gros : factorisation à la place du copier/coller.

      • [^] # Re: systemd

        Posté par  . Évalué à 1.

        ebengin affiche le log en début de ligne.

        eend est appelé après le démarage du démon. Il récupère le code de retour avec $?. Si c’est bon, il écrit un beau ok vert à droite de l’écran, si c’est ko c’est écrit en rouge.

        Et l'init ne peut pas gérer ça tout seul comme un grand ?

        Faut pas se demander pourquoi systemd plait autant aux dévs et admins, c'est pour ce genre de détail : quand tu écris un service, tu n'as pas à te soucier de tout ça, tu te contentes de donner le binaire avec les bonnes options et c'est marre.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: systemd

          Posté par  (site web personnel) . Évalué à 4.

          Ça doit être possible, vu que certains scripts sont réduits au strict minimum. Par exemple, on peut trouver pour umurmur :

          #!/sbin/runscript
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/media-sound/umurmur/files/umurmurd.initd,v 1.1 2013/06/20 09:10:29 polynomial-c Exp $

description="umurmurd - A minimalistic mumble server"
pidfile="/run/umurmurd/umurmurd.pid"
command="/usr/bin/umurmurd"
command_args="-c /etc/umurmur/umurmur.conf -p ${pidfile} ${UMURMURD_OPTS}"
start_stop_daemon_args="-p ${pidfile} -w 100"

depend() {
        need net
        use logger
}

start_pre() {
        checkpath -d -o murmur ${pidfile%/*}
}

        • [^] # Re: systemd

          Posté par  . Évalué à 8.

          Faut pas se demander pourquoi systemd plait autant aux dévs et admins

          source ?

          • [^] # Re: systemd

            Posté par  . Évalué à 1.

            Je sais pas, le fait que pas mal de distributions majeures y migrent ?
            Et même celles qui ne migrent pas laissent la possibilité de l'utiliser.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: systemd

              Posté par  . Évalué à 3.

              c'est pas trop le choix des devs et des admins mais des distributions qui l'imposent quelque soit l'avis des utilisateurs

              • [^] # Re: systemd

                Posté par  . Évalué à 10.

                Les premiers admins des distributions, ce sont ceux qui font les distributions.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: systemd

                  Posté par  . Évalué à 4.

                  Ce ne sont pas forcément ceux qui en ont le plus gros usage

                  Enfin c'était juste pour souligner le fait que sa présence dans les distribs n'en fait pas un choix de prédilection

                  • [^] # Re: systemd

                    Posté par  (site web personnel) . Évalué à 10.

                    En même temps, si ceux qui ont l'usage sont pas ceux qui contribuent, tant pis pour eux. On se gargarise de méritocratie de partout ( bien que ça ne soit pas le cas ), mais dans ce cas précis, c'est les gens qui font qui décident.

                    • [^] # Re: systemd

                      Posté par  . Évalué à 1.

                      D'une part, c'est considérer que dans les distribs, il y a toujours unanimité des choix, ce qui est faux

                      D'autre part, cette histoire permanente de contribution ne devient rien d'autre qu'un prétexte pour envoyer les gens se faire foutre. On ne parle pas d'un micro soft hébergé au milieu de nulle part, mais de distribs qui concernent beaucoup de monde, dont pas mal ne peuvent pas, pour diverses raisons, contribuer.

                      Et pour finir la méritocratie est un mythe qui a fait long feu, on sait que ce sont des fadaises pour enfumer les gens en bas de l'échelle, leur faire croire qu'ils y arriveront un jour et qu'en attendant, il faut bosser comme un chien et bien fermer sa gueule.

                      • [^] # Re: systemd

                        Posté par  (site web personnel) . Évalué à 10.

                        D'une part, c'est considérer que dans les distribs, il y a
                        toujours unanimité des choix, ce qui est faux

                        Tu veux dire quoi par "unanimité dans les distros". Unanimité, ça implique d'avoir un ensemble fini de gens avec des critères, et la, je pense que "une distro", c'est flou. Est ce que la distribution, c'est "tout les gens qui ont le droit de commit", tout les gens qui sont sur une ml, dans un ldap, qui utilisent à un moment T, etc. En général, le but n'est pas d'avoir l'unanimité, c'est bien plus pragmatique que ça, le but est de réduire la maintenance du projet tout en permettant de faire un certains nombres de choses avec le produit.

                        Et bien que ça reste subjectif comme définition, il faut pas oublier que c'est ça. Les gens peuvent rajouter tout ce qu'ils veulent par dessus, à la fin, faut produire un truc. Si ton but n'est pas de sortir un produit, alors c'est pas une distribution que tu fait. Y a rien de mal à ça, c'est juste pas la même chose.

                        D'autre part, cette histoire permanente de contribution ne
                        devient rien d'autre qu'un prétexte pour envoyer les gens se
                        faire foutre.

                        J'aurais tendance à dire que ça peut être pris comme ça, mais en pratique, tu verra que même sans parler de contribution, si quelqu'un dit "faut faire ça" et personne ne le fait, le travail ne se fait pas tout seul et la personne est frustré. D'un point de vue de la dynamique de groupe qui en résulte, vu qu'on veut que le travail se fasse, on récompense ceux qui font le travail par rapport à ceux qui font pas.

                        Que ça soit aliénant pour les gens qui veulent/peuvent pas faire le travail est hélas secondaire, car vu qu'il n'y aucun impact sur la sortie ou non du produit alors il y a aucune boucle de feedback qui fait que dire merde a un effet suffisamment négatif. On pourrait trés bien en effet avoir des gens qui sont la uniquement pour faire le taf de ceux qui peuvent/veulent pas le faire, mais ça ne tient pas la charge. Pour une personne qui va être dans ce groupe, tu va avoir 10, 20 voir plus dans le groupe des gens qui peuvent/veulent pas. Donc à un moment, faut voir les ressources que tu as, et dire non. ( et être gentil en disant 'non' est juste un palliatif pour réduire la frustration mais ça fait pas disparaitre la cause de la frustration, à savoir le fait de pas le faire )

                        Et pour finir la méritocratie est un mythe qui a fait long
                        feu, on sait que ce sont des fadaises pour enfumer les gens en
                        bas de l'échelle

                        C'est bien joli, mais on parle pas d'un vaste système politique qui décide de ta vie de tout les jours, mais de gens qui collabore pour faire un produit, soit sur leur temps libre, soit sur leur temps de travail.

                        Donc même si la méritocratie dans le milieu en général est une fumisterie et ne devrait pas être employé, ça change rien au principe de base que soit les gens bossent, soit les gens bossent pas, et ceux qui bossent pas n'ont pas d'influence parce que ne rien faire ne produit rien.

                        C'est pas parce qu'on dit que c'est une méritocratie qu'il y a une hiérarchie supposé, c'est parce qu'il y a collaboration et dépendance entre les membres du groupe ( ie, les contributeurs du projet comme les non contributeurs, avec toutes les nuances possibles ). C'est parce que l'utilisateur dépend de quelqu'un d'autre ( et dépend de par son propre choix dans pas mal de cas ) qu'il y a une relation de pouvoir de l'un vers l'autre.

                        Dans un échange marchand, je pense que l'équilibre est plus facile à atteindre. IE le vendeur et l'acheteur font un échange. Dans le libre, en renonçant à avoir un truc en retour via un don ( car bosser et filer son code sans que ça coute à la personne qui recoit, c'est ça ), la personne qui fait le don gagne en échange la liberté de pas écouter la personne qui reçoit le dit don ( autrement dit "le droit de dire merde" ).

                        Donc oui, si tu veux avoir plus de pouvoir, il faut contribuer. Sinon quoi que tu fasses, ça sera inégal sauf coercition externe tel qu'on retrouve dans un groupe humain par le biais de la police, de l'ancien du village, de la loi, du shérif, etc. Et à ce moment la, tu as juste passé le pouvoir ailleurs donc tu n'as rien réglé au problème d'égalité de base.

                        En conclusion, ouais, les gens qui font rien par choix ou par contrainte l'auront dans l'os, surtout parce que je pense personne ne doit rien à personne. Personne ne va dire qu'il y a pas de droit inhérent à avoir ses bugs lus et corrigés pour le moment, contrairement au fait d'avoir un toit, etc, et tant de choses dans les droits de l'homme ( et pourtant pas mis en pratique partout ).

                        • [^] # Re: systemd

                          Posté par  . Évalué à 1.

                          Je vais relire un peu plus en détail ton post, en tout cas, il me fait me rendre compte que je n'ai pas été très clair, et que les deux derniers paragraphes de mon post précédent n'étaient pas tant liés à des questions de distributions que des considérations générales

                          • [^] # Re: systemd

                            Posté par  (site web personnel) . Évalué à 6.

                            Non mais tu as raison sur le fait que les gens sortent l'argument de la méritocratie bien souvent pour dire que tout est parfait alors que non. De la même façon que la démocratie n'est pas sans faille ( vu que ça dépend grandement de qui vote, de la façon dont les arguments sont présentés, etc ), mais en effet, la méritocratie est souvent idéalisé alors que c'est pas le cas, y a plein de souci malgré le fait qu'on croit que tout le monde est égal devant la contribution, alors que la seule égalité qu'on a, c'est celle des contraintes du code ( ie, tout le monde ou presque a les mêmes opportunités donnés par une license libre, sauf cas spéciaux ).

                            Il reste à coté les contraintes de temps, de compétences, de trouver des gens proches de chez toi, proche d'un point de vue temporel, proche pour t'aider, etc, etc. Contraintes qu'on peut pas nier, mais contraintes qu'on peut pas résoudre facilement et complétement juste par la volonté et 3/4 lignes en anglais.

                      • [^] # Re: systemd

                        Posté par  . Évalué à 6.

                        D'une part, c'est considérer que dans les distribs, il y a toujours unanimité des choix, ce qui est faux

                        Là tu t'attaque au modèle d'organisation des distributions et tu explique que RedHat, Fedora, Arch et autres ont toutes une organisation suffisamment pourrie pour pouvoir passer en force. L'organisation de la distribution fait parti de ses caractéristiques s'il ne te convient pas c'est que tu t'es trompé de distribution.

                        D'autre part, cette histoire permanente de contribution ne devient rien d'autre qu'un prétexte pour envoyer les gens se faire foutre. On ne parle pas d'un micro soft hébergé au milieu de nulle part, mais de distribs qui concernent beaucoup de monde, dont pas mal ne peuvent pas, pour diverses raisons, contribuer.

                        La contribution c'est le nerd de la guerre dans le libre. Si tu ne contribue pas, t'a que moyennement droit à la parole, je ne vois rien de choquant à cela. Ceux qui ne peuvent pas contribuer, doivent s'adapter je ne vois rien d'illogique à ça. Les contributeurs sont assez libre et ils sont entre autre libres d'envoyer péter les utilisateurs qui leur demandent quelque chose qu'ils n'aiment pas. Si tu ne fais pas de contribution le seul moyen de pression que tu peut avoir c'est d'être suffisamment nombreux pour vouloir partir. Pour le moment je n'ai pas vu de grandes campagnes de départ des distrib' qui sont passé à systemd, c'est que ça ne doit pas être si dramatique que ça.

                        Et pour finir la méritocratie est un mythe qui a fait long feu, on sait que ce sont des fadaises pour enfumer les gens en bas de l'échelle, leur faire croire qu'ils y arriveront un jour et qu'en attendant, il faut bosser comme un chien et bien fermer sa gueule.

                        C'est un modèle théorique, comme la démocratie. On tente de s'en approcher mais rien est parfait. Chaque distribution essaie de s'organiser pour respecter ou non un modèle démocratique, méritocratique ou dictatorial (bienveillant ou pas). Ça n'a rien de nouveau.

                        Je pense aussi que comme pour Gnome, ce n'est pas parce que l'on entends beaucoup de gens crier au loup et annoncer la fin du monde que ça représente la majorité des utilisateurs de ses logiciels.

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

                        • [^] # Re: systemd

                          Posté par  . Évalué à 3.

                          nerd != nerf

                          Faute de frappe?

                          Écrit en Bépo selon l’orthographe de 1990

                          • [^] # Re: systemd

                            Posté par  . Évalué à 6.

                            Oui, mais c'est une assez jolie erreur dans ce domaine :)

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

            • [^] # Re: systemd

              Posté par  (site web personnel) . Évalué à 1.

              Debian propose Exim par défaut, ce qui n'empêche personne d'utiliser postfix à la place, par exemple…

              • [^] # Re: systemd

                Posté par  . Évalué à 3.

                … Parce que SMTP est un standard qui à été formalisé, publié et largement reconnu. Donc tu peux changer d'implémentation quand tu veux.

                Alors que Systemd ne respecte aucun standard et a une API qui contient "systemd" dans le nom.

                • [^] # Re: systemd

                  Posté par  (site web personnel) . Évalué à 2.

                  Clair, tu peux prendre le fichier de config d'Exim et le balancer à Postfix, il le comprendra. je prend un hack Exim et il marchera sous Postfix. Ou pas.
                  systemd lance "httpd" comme d'autres init lancent "httpd", quelle différence avec SMTP?
                  l'API systemd est comme le fichier de config, c'est de la sauce interne, dans les 2 cas c'est incompatible.

                • [^] # Re: systemd

                  Posté par  . Évalué à 10.

                  Alors que Systemd ne respecte aucun standard et a une API qui contient "systemd" dans le nom.

                  Quel standard existe pour l'init actuellement ? Quel standard existe pour le changement d'hostname ?

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: systemd

                    Posté par  . Évalué à -5.

                    Quel standard existe pour l'init actuellement ?

                    LSB.

                    Quel standard existe pour le changement d'hostname ?

                    LSB et la commande hostname. Sachant que la vision ou une machine n'a qu'un seul hostname est … un peu dépassée.

                    • [^] # Re: systemd

                      Posté par  . Évalué à 10.

                      LSB.

                      Donc, je peux prendre un script Debian et le faire tourner sur Red Hat vu qu'il y a un standard ?

                      a commande hostname

                      Ce n'est persistent, c'est justement ce que permet l'API systemd.

                      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                      • [^] # Re: systemd

                        Posté par  . Évalué à -3.

                        Donc, je peux prendre un script Debian et le faire tourner sur Red Hat vu qu'il y a un standard ?

                        Tu peux prendre un script LSB et le faire tourner sur une distribution LSB.

                        Si quelque chose ne marche pas, tu peux examiner la conformité du script et de la distribution et nommer les coupables. C'est ça l'avantage des standards.

                        systemd n'a aucun standard. C'est dommage, parce que qui dit standard, dit au moins qu'il y a plus d'une personne qui à réfléchit au truc. Du coup si je fait une réimplémentation de l'API systemd, qu'un programmeur développe un truc qui marche avec mon implémentation mais pas avec systemd, on ne sait pas de qui c'est la faute.

                        Ce n'est persistent, c'est justement ce que permet l'API systemd.

                        Ce n'est persistent avec systemd que si tu utilise son API. Le noyau en a rien à faire de systemd, et va autoriser n'importe qui à changer le hostname à travers sethostname.

                        Il y a tant de chose à dire aujourd'hui sur [gs]ethostname() et des considérations modernes, comme le fait qu'en 2013 un nom d'hôte à un ou plusieurs mappings vers zéro ou plusieurs adresses IP, et qu'une machine à zéro ou plusieurs adresses IP. Qu'un programme moderne digne de ce nom devrai faire une résolution inverse sur l'IP locale effectivement utilisée pour avoir le nom d'hôte. Si on voulait tout remettre à plat pour le plaisir, on aurai pu faire ça proprement.

                        Mais non, c'est tellement mieux de rester dans le passé.

                      • [^] # Re: systemd

                        Posté par  . Évalué à 1.

                        Donc, je peux prendre un script Debian et le faire tourner sur Red Hat vu qu'il y a un standard ?

                        Ca ne serait pas une norme plutôt comme définition ça?

                        Au delà de ça, pour citer des exemples,
                        Certains compilateurs C ne suivaient pas complètement certaines normes en C
                        Les prises électriques sont toutes normées pourtant leurs formes diffèrent suivant les pays.

    • [^] # Re: systemd

      Posté par  . Évalué à 1.

      Pour les performances, cherche pas, on te dira que blabla c’est pas nécessaire sur serveur et que sur le bureau tout le monde utilise systemd de toutes façons.

      En tout cas entre SystemD et OpenRC y'a pas photo, surtout que j'ai jamais réussi à faire du lancement parallèle avec OpenRC sans bugs.

      Les autres, pas fait de comparaison sérieuses, mais pas l'air très véloces. Après ça vient plus de la lourdeurs des script que des choix technologiques eux-mêmes, regarde les scripts d'init "SysV" de Debian ou RHEL ça reimplemente tout "mount -a" en Bash directement dans l'initscript.

      Alors quand je lis que les *BSD ont remplacés des milliers de ligne en shell d'init par une commande "jail -c" je dit bravo, c'est dans ce sens qu'il faut aller, et c'est ce sens qu'encourage SystemD en "virant" l'interprétation shell des fichiers de définition des services.

    • [^] # Re: systemd

      Posté par  (site web personnel) . Évalué à 10.

      Rho le gros pâté de shell… Bah c’est pas très beau, mais bon faudrait une vraie comparaison (même démon et code équivalent).

      Un paté de shell ça vaut un paté de python, de C, ou de n'importe quoi d'autre, je ne vois pas le problème. La fonction ici implémentée en [a]sh peut être implémentée ailleurs et autrement, il n'en reste pas moins qu'il faut l'implémenter quelque part: si ce n'est pas dans ce script, ce peut-être directement dans le logiciel d'init ou par ajout d'une option à la commande qui va bien, mais, je le répète, ça doit bien être implémenté quelque part.

      L'intérêt du shell, à mon avis, c'est que c'est le langage par défaut d'administration de la machine, et celui qu'on trouve par défaut en console. On y est confronté à un moment ou un autre, et normalement, on apprend à le connaître et à le maîtriser. C'est, pour l'utilisateur final, une certaine garantie quant à la possibilité de toucher à son init.

      Et de fait, lorsqu'on veut faire quelque chose qui sort des clous, le plus simple reste d'écrire un script shell. Je crois que même avec systemD, dans certains cas particulier, l'administrateur n'a pas d'autre choix que d'écrire un script shell qui va bien.

      Pour ma part, j'ai souvent du modifier l'init réseau pour qu'il gère correctement ma configuration du wifi. Peu à peu, la procédure s'est normalisée, et maintenant ces hacks ne sont plus nécessaires. Mais j'imagine qu'il y aura toujours des situations où ce qu'ont prévu les développeurs d'init et les distributions ne correspond pas à une situation particulière.

      • [^] # Re: systemd

        Posté par  . Évalué à -1.

        Un paté de shell ça vaut un paté de python, de C, ou de n'importe quoi d'autre, je ne vois pas le problème.

        Le problème, c'est justement le langage shell

        L'intérêt du shell, à mon avis, c'est que c'est le langage par défaut d'administration de la machine, et celui qu'on trouve par défaut en console. On y est confronté à un moment ou un autre, et normalement, on apprend à le connaître et à le maîtriser. C'est, pour l'utilisateur final, une certaine garantie quant à la possibilité de toucher à son init.

        On peut toujours se toucher l'init avec systemd, je vois pas le rapport. Les unit files sont documentés, et beaucoup plus simple que des scripts d'init. Et la soixantaine de binaires qui viennent avec systemd donne largement de quoi se toucher l'init.

        Et de fait, lorsqu'on veut faire quelque chose qui sort des clous, le plus simple reste d'écrire un script shell. Je crois que même avec systemD, dans certains cas particulier, l'administrateur n'a pas d'autre choix que d'écrire un script shell qui va bien.

        Y'a toujours une compatibilité avec les scripts shells, mais tu passes alors à côte de pas mal d'intérêts de systemd (comme éviter de lancer au minimum deux processus - un shell, lequel lance le programme/script - pour une tâche d'init, avoir quelque chose de plus facilement lisible et déboguable qu'un script shell, …)

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: systemd

        Posté par  . Évalué à 5.

        J'ai rien contre le langage shell, mais en mettre un gros pâté dans un initscript est pour moi un indicateur de solution gruik posée à la va-vite. Se sera pas pas portable (bash d'un coté, Ash de l'autre, paths hardcodés, appels de fonctions spécifiques…), pas porté (chacun fera sa petite cuisine dans son coin), inélégant, le contraire du prétendu "esprit" du SysV RC qu'on nous chantes chaque fois qu'on parle de SystemD.

        En des temps immémoriaux, à ma première LSF, pour monter les systèmes de fichiers l'initscript était un simple appel à mount -a.
        Maintenant pour faire ça t'a des centaines de lignes dans /etc/rc.sysvinit pour RHEL, Pour Debian des milliers de lignes dans /etc/init.d et /etc/network/if-up.d…

        Bon ces scripts font des choses utiles genre attendre le réseau pour monter du NSF, des dizaines de mainteneurs de distributions ont implémentés ce genre de truc, mais personne n'a penser à moderniser mount pour qu'ils réponde aux nouveaux besoins de l'init, alors que c'est son rôle : 

         mount -a [-t type] [-O optlist]

                  (**usually given in a bootscript**) causes all filesystems mentioned in fstab (of the proper type
          and/or having or not having the proper options) to be mounted as indicated, except for those
          whose line contains the noauto keyword. Adding the -F option will make mount fork, so that the
          filesystems are mounted simultaneously.

        Des scripts shell je suis le premier à en faire, mais dès que tu te pose la question "comment faire ça proprement ?" ben tu les sort de l'init.

        Avec LXC beaucoup de distributions ont ajoutés un initscript "complexe" pour lancer de containers au démarrage.
        Alors c'est pratique, tu file le nom de tes containers dans /etc/default/lxc et ils seront démarrés/arrêtés automatiquement.
        Mais si j'en arrête un par moi même, l'init gueulera à l’arrêt du service que toto était lancé et qu'il ne l'est plus, ou plein d'autres petits dysfonctionnements.

        On s’aperçoit vite que pour faire ça proprement, il faut un système qui permette la gestion complète des containers "automatiques" ajout/suppression/démarrage/arrêt/démarrage-individuel/arrêt-individuel/statut d'un containers/statut de tous les containers… et que la place d'un tel utilitaire n'est pas dans l'init, par contre un l'init peut appeler cet utilitaire pour le démarrage/arrêt du service.

        Après faire ça en shell, pourquoi pas, c'est un choix de langage comme un autre.

        • [^] # Re: systemd

          Posté par  . Évalué à 4.

          Se sera pas pas portable (bash d'un coté, Ash de l'autre, paths hardcodés, appels de fonctions spécifiques…)

          Il y a quelque temps de cela, des gens se sont mis autour d'une table et ont écrit un truc nommé standard qu'ils ont appelé POSIX.
          Ash est une implémentation du shell POSIX. Donc, en théorie, tout ce qui tourne avec Ash tourne avec n'importe quel shell POSIX. D'où l'intérêt.

          • [^] # Re: systemd

            Posté par  (site web personnel) . Évalué à 4.

            Non ; la bonne phrase est « ce qui tourne avec Ash et qui est compatible POSIX tourne avec n'importe quel shell POSIX ».

            Quasiment chaque shell (et on peut dire la même chose de beaucoup d'outils GNU) a ses extensions qui ne sont pas compatibles POSIX.
            Du coup, quand tu écris ton script shell, il faut avoir en mémoire ce qui est spécifique à Ash (ou Zsh, Bash, …) et ce qui est purement POSIX… C'est très loin d'être évident.

            • [^] # Re: systemd

              Posté par  . Évalué à 3. 

               The sh utility is the standard command interpreter for the system.  The
 current version of sh is close to the IEEE Std 1003.1 (``POSIX.1'')
 specification for the shell.  It only supports features designated by
 POSIX, plus a few Berkeley extensions.

              En pratique, ces extensions sont très très limitées, comme par exemple le support de "echo -n" qui n'est pas strictement POSIX. Mais je serais curieux de trouver un script qui tourne sous ash mais pas sous bash/zsh/{m,pd,}ksh/csh.

              Le vrai problème se situe plus dans les commandes appelées, mais il suffit de lire attentivement la section "Conforming to" des pages de manuels, comme quand tu codes en C.

            • [^] # Re: systemd

              Posté par  (site web personnel) . Évalué à 3.

              Dans le cas de Debian, les scripts init doivent utiliser uniquement dash (The Debian Almquist Shell (dash) is a POSIX-compliant shell derived from ash), le shell par défaut "/bin/sh" est maintenant un lien symbolique vers dash. Les script init ont été corrigés, les rapports de bug étaient taggués "bashism".

              • [^] # Re: systemd

                Posté par  (site web personnel) . Évalué à 5.

                Tiens, petite anecdote à propos de cette approche de lien symbolique. Au temps de KDE 2, je me souviens qu'ils avaient travaillé sur l'optimisation du temps de lancement de KDE. Ils avaient constaté que certains services KDE qui sont lancés par Shell étaient lancés avec /bin/sh mais en fait étaient lancés par /bin/bash à cause des liens symboliques, et bash prenaient énormément de temps à démarrer, parce que le shell est bien plus compliqué que sh.

                Au final, trouver le vrai sh ou remplacer les scripts triviaux par un programme en C plus simple avait fait un gain significatif sur le temps de lancement.

          • [^] # Re: systemd

            Posté par  . Évalué à 3. Dernière modification le 05 décembre 2013 à 13:10.

            C'est pas comme si j'avais pas cité les bashisms entre-autres.
            Quasiment toutes les distribs sont passés à du pure SH (Debian, Gentoo…), mais reste quelques bashisms chez RH par ex, et si l'auteur d'un programme fournit un initscript pour RH, ben ça marchera pas ailleurs.

            Après, tous ces init utilisent le même langage, mais pas les mêmes fonctions,
            CentOS : /etc/rc.d/init.d/functions
            Debian : /lib/lsb/init-functions
            Gentoo : /lib/rc/sh/runscript.sh

            Et ces fichiers contiennent tous des commandes spécifiques à chaque init (log_warning_msg pour un, ewarn pour l'autre…)

            Sortir le gros de la gestion du daemon hors de l'init permet un meilleur contrôle de l'utilisateur via un outil unifié, mais aussi de minimiser le code spécifique à la distribution.

            Après bizarre de voir les bsdistes me tomber dessus alors que j'ai cité jail en bon exemple, mais bon j'ai dit systemd, c'est un gros mot.

      • [^] # Re: systemd

        Posté par  (site web personnel) . Évalué à 8.

        L'intérêt du shell, à mon avis, c'est que c'est le langage par
        défaut d'administration de la machine, et celui qu'on trouve par
        défaut en console. On y est confronté à un moment ou un autre,
        et normalement, on apprend à le connaître et à le maîtriser.

        Permet moi de douter la capacité des gens à maitriser le shell.

        Il suffit de voir le simple fait que les gens confondent shell et bash, il suffit de voir le nombre de gens qui utilisent pas trap dans leur code, le nombre de gens pour qui la syntaxe ${i#plop#coin} va être trop ésotérique, le nombre de gens qui savent pas qu'il faut éviter d'utiliser /tmp et que le shell est le seul language ou tu peux pas garantir de faire ça de façon parfaitement propre sans race condition.

        Dire que le shell, c'est bien parce que tout le monde comprends, c'est comme dire que php est bien car tout le monde sait en faire.

        • [^] # Re: systemd

          Posté par  (site web personnel) . Évalué à 2.

          Tu as mille fois raison, « maîtriser » était de trop dans ma phrase.

          Mais je ne dis pas que le shell c'est bien parce que tout le monde comprend, je dis surtout que c'est parce que c'est l'outil par défaut qu'on apprend à le connaître. C'est le fait d'utiliser l'outil par défaut pour les scripts du système de base qui me semble pertinent.

          On pourrait préférer avoir un autre outil par défaut, mais là n'est pas la question. On pourrait aussi considérer que l'idée d'un outil par défaut n'est pas bonne – là est peut-être la question.

    • [^] # Re: systemd

      Posté par  . Évalué à 10.

      Rho le gros pâté de shell… Bah c’est pas très beau, mais bon faudrait une vraie comparaison (même démon et code équivalent).

      Je suis un type allergique au shell, quand ça dépasse 500 lignes. Mais là, ce n'est pas le cas :

      wc -l etc/rc                                                                                                  
74 etc/rc

      J'ai pas tendance à appeler 74 lignes "un gros paquet". Suivant ton raisonnement, je dirais que systemd c'est "un gros paquet de C".
      Si tu parles des scripts rc, écrits par les mainteneurs, ils ont une syntaxe claire, et offrent une plus grande souplesse de configuration que les unit systemd. Regardons si cette souplesse conduit à "un gros paquet" :

      systemd :

      [Unit]
Description=PostgreSQL database server
After=network.target

[Service]
Type=forking
TimeoutSec=120
User=postgres
Group=postgres

Environment=PGROOT=/var/lib/postgres

SyslogIdentifier=postgres
PIDFile=/var/lib/postgres/data/postmaster.pid

ExecStartPre=/usr/bin/postgresql-check-db-dir ${PGROOT}/data
ExecStart= /usr/bin/pg_ctl -s -D ${PGROOT}/data start -w -t 120
ExecReload=/usr/bin/pg_ctl -s -D ${PGROOT}/data reload
ExecStop=  /usr/bin/pg_ctl -s -D ${PGROOT}/data stop -m fast

# Due to PostgreSQL's use of shared memory, OOM killer is often overzealous in
# killing Postgres, so adjust it downward
OOMScoreAdjust=-200

[Install]
WantedBy=multi-user.target

      Taille :
      26 lignes.
      Documentation :
      aucune.
      Coniguration :
      Possibilité de configurer le dossier contenant les fichiers de la base de donnée.

      rcNG :

      # PROVIDE: postgresql
# REQUIRE: LOGIN
# KEYWORD: shutdown
#
# Add the following line to /etc/rc.conf to enable PostgreSQL:
#
#  postgresql_enable="YES"
#  # optional
#  postgresql_data="/usr/local/pgsql/data"
#  postgresql_flags="-w -s -m fast"
#  postgresql_initdb_flags="--encoding=utf-8 --lc-collate=C"
#  postgresql_class="default"
#  postgresql_profiles=""
#
# See /usr/local/share/doc/postgresql/README-server for more info
#
# This scripts takes one of the following commands:
#
#   start stop restart reload status initdb
#
# For postmaster startup options, edit ${postgresql_data}/postgresql.conf

command=/usr/local/bin/pg_ctl

. /etc/rc.subr

load_rc_config postgresql

# set defaults
postgresql_enable=${postgresql_enable:-"NO"}
postgresql_flags=${postgresql_flags:-"-w -s -m fast"}
postgresql_user=${postgresql_user:-"pgsql"}
eval postgresql_data=${postgresql_data:-"~${postgresql_user}/data"}
postgresql_class=${postgresql_class:-"default"}
postgresql_initdb_flags=${postgresql_initdb_flags:-"--encoding=utf-8 --lc-collate=C"}

name=postgresql
rcvar=postgresql_enable
extra_commands="reload initdb"

start_cmd="postgresql_command start"
stop_cmd="postgresql_command stop"
restart_cmd="postgresql_command restart"
reload_cmd="postgresql_command reload"
status_cmd="postgresql_command status"

initdb_cmd="postgresql_initdb"

if [ -n "$2" ]; then
        profile="$2"
        if [ "x${postgresql_profiles}" != "x" ]; then
                eval postgresql_data="\${postgresql_${profile}_data:-}"
                if [ "x${postgresql_data}" = "x" ]; then
                        echo "You must define a data directory (postgresql_${profile}_data)"
                        exit 1
                fi
                eval postgresql_enable="\${postgresql_${profile}_enable:-${postgresql_enable}}
                eval postgresql_data="\${postgresql_${profile}_data:-${postgresql_data}}
                eval postgresql_flags="\${postgresql_${profile}_flags:-${postgresql_flags}}"
                eval postgresql_initdb_flags="\${postgresql_${profile}_initdb_flags:-${postgresql_initdb_flags}}"
        fi
else
        if [ "x${postgresql_profiles}" != "x" -a "x$1" != "x" ]; then
                for profile in ${postgresql_profiles}; do
                        eval _enable="\${postgresql_${profile}_enable}"
                        case "x${_enable:-${postgresql_enable}}" in
                        x|x[Nn][Oo]|x[Nn][Oo][Nn][Ee])
                                continue
                                ;;
                        x[Yy][Ee][Ss])
                                ;;
                        *)
                                if test -z "$_enable"; then
                                        _var=postgresql_enable
                                else
                                        _var=postgresql_"${profile}"_enable
                                fi
                                echo "Bad value" \
                                        "'${_enable:-${postgresql_enable}}'" \
                                        "for ${_var}. " \
                                      "Profile ${profile} skipped."
                                continue
                                ;;
                        esac
                        echo "===> postgresql profile: ${profile}"
                        /usr/local/etc/rc.d/postgresql $1 ${profile}
                        retcode="$?"
                        if [ "0${retcode}" -ne 0 ]; then
                                failed="${profile} (${retcode}) ${failed:-}"
                        else
                                success="${profile} ${success:-}"
                        fi
                done
                exit 0
        fi
fi

command_args="-D ${postgresql_data} ${postgresql_flags}"

postgresql_command()
{
    su -l ${postgresql_user} -c "exec ${command} ${command_args} ${rc_arg}"
}

postgresql_initdb()
{
    su -l -c ${postgresql_class} ${postgresql_user} -c "exec /usr/local/bin/initdb ${postgresql_initdb_flags} -D ${postgresql_data}"
}

run_rc_command "$1"

      taille :
      114 lignes.
      Documentation :
      les valeurs de configuration possibles sont documentées.
      Configuration :
      possibilité de choisir les options de la base de donnée, de créer une nouvelle base de donnée, et de choisir plusieurs profils.

      Ramenons maintenant cela au même niveau de fonctionnalité que systemd :

      # PROVIDE: postgresql
# REQUIRE: LOGIN
# KEYWORD: shutdown

command=/usr/local/bin/pg_ctl

. /etc/rc.subr

# set defaults
postgresql_enable=${postgresql_enable:-"NO"}
eval postgresql_data=${postgresql_data:-"~${postgresql_user}/data"}

name=postgresql
rcvar=postgresql_enable

start_cmd="postgresql_command start"
stop_cmd="postgresql_command stop"
restart_cmd="postgresql_command restart"
reload_cmd="postgresql_command reload"
status_cmd="postgresql_command status"

postgresql_command()
{
    su -l pgsql -c "exec ${command} -D ${postgresql_data}  -w -s -m fast ${rc_arg}"
}

run_rc_command "$1"

      Lignes :
      27

      Ça ressemble vachement à systemd, j'ai l'impression. Des déclarations de variables pour les commandes à éxécuter, avec la possibilité de factoriser le code dans une fonction. J'ai l'impression que ton commentaire sur la syntaxe illisible est un troll, je te mets au défi de me donner un argument objectif sur ce point.

      • [^] # Re: systemd

        Posté par  . Évalué à 1.

        Je suis plutôt d’accord, néanmoins quelques points sur lesquels je souhaiterais discuter.

        Tout d’abord, la documentation dans le script, je trouve ça bof. Évidemment si tu veux modifier le script tu peux te faire plaisir, mettre de la documentation concernant le fonctionnement interne et les variables, etc. Pour les utilisateurs, systemd offre la commande systemctl help [nom de l’unité]. C’est dommage, ça n’offre que la documentation pour les trucs internes à systemd pour le moment, mais c’est un truc qui existe depuis le début (systemd est très bien documenté depuis le début d’après ce que j’ai pu voir).

        D’autre part, même à fonctionnalité égale la syntaxe des fichiers d’unité systemd est plus sympa, avec User, Group ou TimeoutSec, OOMScoreAdjust (ces dernières fonctionnalités semblent manquer dans ton exemple…). Dans tous les cas, oui on peut faire aussi cours ou presque en script Shell, mais le fait d’utiliser des champs déclaratifs et pas des scripts ça permet d’introduire facilement un comportement unifié, sans pour autant empêcher de faire un script Shell! Du coup, on pourrait tout à fait utiliser le script Shell de l’unité rcNG et l’utiliser en conjonction avec systemd. Ça serais sans doute légèrement plus propre. Dans tous les cas c’est pas le script Shell qui m’intéresse mais ce qui gravite autour et qui est assez rébarbatif à faire, et sur ce point-là systemd est quand même bon.

        Enfin,

        # Add the following line to /etc/rc.conf to enable PostgreSQL:
#
#  postgresql_enable="YES"
#  # optional
#  postgresql_data="/usr/local/pgsql/data"
#  postgresql_flags="-w -s -m fast"
#  postgresql_initdb_flags="--encoding=utf-8 --lc-collate=C"
#  postgresql_class="default"
#  postgresql_profiles=""

        Je trouve pas ça super propre quand une commande peut faire les choses à notre place en faisant toutes les vérifications nécessaires (systemctl…), même si c’est ce que je faisais avec le /etc/rc.conf d’Arch Linux. Par contre je sais pas du tout comment on peut gérer les variables de ce type dans systemd, est-ce que quelqu’un a une idée de comment ça se fait? Perso je préfère laisser le logiciel tel quel sans script fait par la distro (mais c’est sans doute parce que je suis archlinuxien), mais pour d’autres distributions ça a un intérêt certains.

        Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: systemd

          Posté par  . Évalué à 3. Dernière modification le 04 décembre 2013 à 20:32.

          Tout d’abord, la documentation dans le script, je trouve ça bof.

          Literate programming FTW ! Plus sérieusement, je vois pas trop où la mettre d'autre, créer une page de manuel pour chaque script d'init semble un peu overkill.

          D’autre part, même à fonctionnalité égale la syntaxe des fichiers d’unité systemd est plus sympa, avec User, Group ou TimeoutSec, OOMScoreAdjust (ces dernières fonctionnalités semblent manquer dans ton exemple…).

          Mais, ce que j'essaye de dire, c'est que la syntaxe, c'est là même à 5 caractères près :

          postgresql_user=pgsql

          vs 

          User=pgsql

          Franchement, faut être exigeant pour trouver l'une plus moche que l'autre ! L'overhead de :

          postgresql_user=${postgresql_user:-"pgsql"}

          est là pour permettre de configurer ça dans /etc/conf.d ou /etc/rc.conf justement. (ça veut dire, "si la variable est indéfinie, alors assigner "pgsql" comme valeur par défaut").

          Dans tous les cas c’est pas le script Shell qui m’intéresse mais ce qui gravite autour et qui est assez rébarbatif à faire, et sur ce point-là systemd est quand même bon.

          Tu parles de quoi, par exemple par curiosité ?

          Je trouve pas ça super propre quand une commande peut faire les choses à notre place en faisant toutes les vérifications nécessaires (systemctl…)

          Je suis curieux de savoir ce que tu entends par là

          • [^] # Re: systemd

            Posté par  . Évalué à 1.

            Literate programming FTW ! Plus sérieusement, je vois pas trop où la mettre d'autre, créer une page de manuel pour chaque script d'init semble un peu overkill.

            C’est vrai que ce côté-là, chacun son avis. Dans tous les cas, je pointe le fait que ça peut être fait avec systemd mais que ça n’est actuellement pas fait parce que comme il n’y a pas de scripts, forcément il n’y a pas besoin de variables, et les actions sont standard (start, stop, restart…).

            Mais, ce que j'essaye de dire, c'est que la syntaxe, c'est là même à 5 caractères près :
            […]

            Je suis d’accord, mais je dis que dans certaines circonstances ça peut être plus flexibles. Imaginons la X=truc, si un jour je décide de désactiver la fonctionnalité X de systemd, on pourra ne plus en tenir compte. Parce qu’on a beau vanter le fait que le Shell c’est turing-complet, il faut voir que de l’autre côté on a toujours le côté turing-complet mais avec l’avantage de l’unification de pas mal de variables.

            Franchement, faut être exigeant pour trouver l'une plus moche que l'autre ! L'overhead de :

            
est là pour permettre de configurer ça dans /etc/conf.d ou /etc/rc.conf justement. (ça veut dire, "si la variable est indéfinie, alors assigner "pgsql" comme valeur par défaut").

            Hum faudrait regarder du côté de systemd comment ça se gère, j’avoue que je ne sais pas si on peut redéfinir la variable d’une unité.

            Dans tous les cas c’est pas le script Shell qui m’intéresse mais ce qui gravite autour et qui est assez rébarbatif à faire, et sur ce point-là systemd est quand même bon.
            Tu parles de quoi, par exemple par curiosité ?

            Bah les User, Group, toutes les variables quoi.

            Je trouve pas ça super propre quand une commande peut faire les choses à notre place en faisant toutes les vérifications nécessaires (systemctl…)
            Je suis curieux de savoir ce que tu entends par là

            Bah pas de trucs à recopier dans un fichier de configuration, impossible de se tromper sur un nom de démon du coup, et puis il y a des fonctionnalités en plus (conf temporaire par exemple)! Extrait du man de systemctl pour la commande systemctl enable NAME:

            Enable one or more unit files or unit file instances, as specified on the command line. This will create a number of symlinks as encoded in the "[Install]" sections of the unit files. After the symlinks have been created, the systemd configuration is reloaded (in a way that is equivalent to daemon-reload) to ensure the changes are taken into account immediately. Note that this does not have the effect of also starting any of the units being enabled. If this is desired, a separate start command must be invoked for the unit. Also note that in case of instance enablement, symlinks named the same as instances are created in the install location, however they all point to the same template unit file.

[…]

Depending on whether --system, --user, --runtime, or--global, is specified, this enables the unit for the system, for the calling user only, for only this boot of the system, or for all future logins of all users, or only this boot. Note that in the last case, no systemd daemon configuration is reloaded.

            Écrit en Bépo selon l’orthographe de 1990

            • [^] # Re: systemd

              Posté par  . Évalué à 2.

              Je suis d’accord, mais je dis que dans certaines circonstances ça peut être plus flexibles. Imaginons la X=truc, si un jour je décide de désactiver la fonctionnalité X de systemd, on pourra ne plus en tenir compte. Parce qu’on a beau vanter le fait que le Shell c’est turing-complet, il faut voir que de l’autre côté on a toujours le côté turing-complet mais avec l’avantage de l’unification de pas mal de variables.

              Je vois pas du tout en quoi tu peux pas faire ça avec du shell et une lib comme rc.subr. D'ailleurs, si tu définis une variable qui n'est plus utilisée par la suite, elle n'est juste plus utilisée; Pas de soucis.

              Sinon, je suis curieux de voir une machine de turing écrite en systemd :].

              Bah pas de trucs à recopier dans un fichier de configuration, impossible de se tromper sur un nom de démon du coup, et puis il y a des fonctionnalités en plus (conf temporaire par exemple)! Extrait du man de systemctl pour la commande systemctl enable NAME:

              Un peu comme, avec rcNG, rcenable NAME et rcdisable NAME tu veux dire ?

              • [^] # Re: systemd

                Posté par  . Évalué à 1.

                Je vois pas du tout en quoi tu peux pas faire ça avec du shell et une lib comme rc.subr. D'ailleurs, si tu définis une variable qui n'est plus utilisée par la suite, elle n'est juste plus utilisée; Pas de soucis.

                On s'est mal compris je crois. Ce que je veux dire, c'est qu'on pourrait imaginer (je sais pas si ça existe déjà ou existera, mais ça n'est qu'un exemple) qu'on dise à systemd d'ignorer telle variable, et ce pour toutes les unités.

                J'ai du mal à voir comment on pourrait faire ça avec les script d'initialisation, et même si c'est possible de façon propre. Mais sur ce coup-là, je dis peut-être une énorme connerie.

                Un peu comme, avec rcNG, rcenable NAME et rcdisable NAME tu veux dire ?

                Probablement. Je pensais que c'était comme feu l'init à la BSD d'Arch Linux Faudrait que je regarde à nouveau mais il me semblait qu'avec Upstart fallait se farcir les liens symboliques à la main, c'est sans doute faux à l'heure actuelle.

                Écrit en Bépo selon l’orthographe de 1990

            • [^] # Re: systemd

              Posté par  (site web personnel) . Évalué à 4.

              Hum faudrait regarder du côté de systemd comment ça se gère, j’avoue que je ne sais pas si on peut redéfinir la variable d’une unité.

              Euh. Ça veut dire qu'il n'est pas possible de spécifier les flags des services ou un minimum de config ?
              Ou il faut le faire directement dans le fichier unit de systemd ? Comment ça se passe alors lors d'une mise à jour ? Les units sont mergées ?

              Avoir la configuration séparée des scripts d'init (comme un rc.conf) ça a quand même du bon à ce niveau. J'imagine mal qu'on puisse se satisfaire des flags par défaut dans tous les cas.

              C'est une vrai question.

              les pixels au peuple !

              • [^] # Re: systemd

                Posté par  . Évalué à 8.

                Les units systemd installés par des packages sont placés dans le repertoire /usr/lib/systemd/system (ou le repertoire renvoyé par la commande pkg-config systemd --variable=systemdsystemunitdir).

                Si on a besoin de modifier un unit systemd, on le copie d'abord dans le repertoire /etc/systemd/system et on le modifie. systemd va utiliser en priorité la version qui est dans /etc/systemd/system.

                Avec les versions recentes de systemd il est maintenant possible de modifier certaines variables sans copier le fichier entierement. Pour cela, pour modifier une variable de foobar.service on crée le repertoire /etc/systemd/system/foobar.service.d/ dans lequel on met un fichier *.conf contenant uniquement les variables à modifier.

                https://lwn.net/Articles/542609/

                • [^] # Re: systemd

                  Posté par  (site web personnel) . Évalué à 2.

                  On noteras que upstart supporte aussi un mécanisme semblable sur les versions récentes :

                  http://upstart.ubuntu.com/cookbook/#override-files

                  • [^] # Re: systemd

                    Posté par  (site web personnel) . Évalué à 1. 

                    On noteras que upstart supporte aussi un mécanisme semblable sur les versions récentes :

http://upstart.ubuntu.com/cookbook/#override-files

                    Non, override permet de dire si on veut activer ou non un service. Il n'est pas possible de modifier l'équivalent du fichier "unit". Cela n'a rien à voir.

                    • [^] # Re: systemd

                      Posté par  (site web personnel) . Évalué à 2.

                      si tu lis le lien que je donnes, tu va voir que ça permet plus que de dire si tu veux activer ou pas le job : 

                      "Change a Jobs Start/Stop Conditions"

                      Ou

                      "Adding Stanzas that are Not Present in the .conf File"

                      Donc je persiste qu'il est possible de rajouter des choses de façon semblable. C'est pas aussi bien que systemd, certes, mais tu peux totalement remplacer le contenu du fichier job, comme dit toujours dans le lien :

                      "Note: We assume here that the corresponding /etc/init/my-daemon.conf file does not already specify a pre-start since if it did, our override file would replace it."

      • [^] # Re: systemd

        Posté par  . Évalué à -2.

        Intéressante ta comparaison.
        Effectivement cela a l'air équivalent a première vue.
        Juste 2-3 question, si tu me permet.

        Ou est la définition de pré-dépendance de service dans le script?
        Ou est la valeur de time-out dans le script?
        Ou est la limitation OOMkiller?
        Ou sont les dépendances des services qui demande ce service?
        Comment ce script ou initrc (ou autre) assure l'isolation du cgroup?

        Apres sur la doc, bizarrement j'ai tendance a penser que l'unit systemd est très explicité et lisible, en tout cas plus que le script présenté.
        A quelle point ce script varie d'une distro a l'autre? d'une version a l'autre? comparais a une unité systemd?

        systemd permet d'avoir bien plus d'option encore dans une unité, cela serais t'il facile a mettre en oeuvre avec ce script? jusqu’à quelle point?
        option dans systemd http://www.freedesktop.org/software/systemd/man/systemd.unit.html

        Mais je suis certain que pour n'importe quelle admin pressé cela doit pouvoir se faire le doigt dans le nez… Non???

        • [^] # Re: systemd

          Posté par  (site web personnel) . Évalué à 6.

          Ou est la définition de pré-dépendance de service dans le script?

          REQUIRE: LOGIN

          Ou est la valeur de time-out dans le script?

          Y'a pas, soit ça démarre soit ça démarre pas…

          Ou est la limitation OOMkiller?

          On a pas ce truc sous FreeBSD.

          Ou sont les dépendances des services qui demande ce service?

          Dans les définitions de ces services. Je ne vois pas comment un service peut savoir qui a besoin de lui.
          (sinon tu as le PROVIDE:)

          Comment ce script ou initrc (ou autre) assure l'isolation du cgroup?

          On n'a pas ça non plus :)

          les pixels au peuple !

      • [^] # Re: systemd

        Posté par  . Évalué à 6.

        Et ce serait pas intéressant de pouvoir rajouter, supprimer, changer, monitorer les instances de postgresql démarrées par l'init via un petit utilitaire ?

        Certes on peut rajouter des commandes à /etc/init.d/postgresql, mais autant faire un truc qui marchera partout non ?

        Et puis je suis pas fan perso quand l'init fait trop de choses sans même me demander mon avis.

        Tu démarre le service pour la première fois t'a une base de données utilisable, bien, très bien, mais si tu ne voulait pas ça ? Si tu voulait importer ta base de données avant ? Raté ! apt-get install postgresql lancera automatiquement l'initscript qui va te créer une base inutile et quand tu va importer la tienne après, l'initscript va gueuler que l'instance 9.1/main entre en conflit avec l'instance 9.1/main. Obligé d'aller lire le contenu du script pour voir comment il fonctionne et comment déboguer alors qu'une commande externe aurait eu sa page de manuel.

        Et puis n’espérez transférer une base de donnée de RHEL à Debian comme-ça, la façon dont sont choisies les instances à démarrer est spécifique à chaque distrib, le transfert ne se fera pas sans mal.

      • [^] # Re: systemd

        Posté par  . Évalué à 1.

        Ces évaluations de lignes sont totalement fausses.
        Il y a inclusion d'un autre script (qui lui-même en inclus d'autres) dans les scripts shell, spécifiquement de /etc/rc.subr, qu'il faut ajouter au nombre de lignes nécessaires pour que cela fonctionne. Ce qui rajoute plusieurs dizaines de lignes tout de suite (surement plus de 200 lignes).
        Le script rc ne ressemble pas du tout à du systemd : par exemple, de la configuration est accédée par rc.subr, ce qui n'est pas le cas dans systemd où toute la configuration pour le service est soit dans l'initscript soit gérée par le service dans sa propre configuration.

        Dans la suite des procédés malhonnêtes, indiquer qu'il n'y a pas de documentation dans le fichier systemd alors que cela dépend entièrement du mainteneur.
        Il y a possibilité de mettre des commentaires de la même façon comme on peut le voir d'ailleurs dans l'exemple fourni, et même une directive "documentation" pouvant référencer man.

        Et non, le script rc n'est pas du tout lisible au niveau syntaxe, la configuration est chargée et se trouve dans un autre fichier, enfin bref c'est un bordel sans nom, comme les initscripts SYSV d'ailleurs. Ce genre de trucs est très difficile à maintenir.

        Avec systemd on ne code pas dans les initscripts, c'est censé être déclaratif, c'est un de ses points forts. L'initscripts est le dernier endroit où je veux du code.

        • [^] # Re: systemd

          Posté par  . Évalué à 0.

          Mais tu comprends, si l'init n'offre pas un langage turing-complet, il vaut rien ! /o\

          Le nouvel init de l'an prochain sera en Java, et il déchirera tout ! \o/

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: systemd

            Posté par  . Évalué à 3.

            En Java 2E même.

            Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: systemd

          Posté par  . Évalué à 2.

          Dans la suite des procédés malhonnêtes, indiquer qu'il n'y a pas de documentation dans le fichier systemd alors que cela dépend entièrement du mainteneur.
          Il y a possibilité de mettre des commentaires de la même façon comme on peut le voir d'ailleurs dans l'exemple fourni, et même une directive "documentation" pouvant référencer man.

          C'est meme une bonne chose qu'il n'y ait pas de commentaires dans le fichier unit. Les directives utilisées étant standard, c'est deja documenté dans les pages man de systemd, pas besoin de rajouter des commentaires sauf cas particulier.

        • [^] # Re: systemd

          Posté par  . Évalué à 6.

          Il y a inclusion d'un autre script (qui lui-même en inclus d'autres) dans les scripts shell, spécifiquement de /etc/rc.subr, qu'il faut ajouter au nombre de lignes nécessaires pour que cela fonctionne. Ce qui rajoute plusieurs dizaines de lignes tout de suite (surement plus de 200 lignes).

          Impressionant comme raisonnement. rc.subr c'est l'init en lui même, ce n'est pas quelque chose que tu vas modifier toi même.

          Un script systemd fait donc 1,5 millions de ligne de code, si on inclue tout le code de systemd. D'ailleurs, je me demande s'il ferait pas plusieurs 10aines de millions, car il a besoin de gcc pour fonctionner. En fait, ça doit même dépasser ça si on inclue le code de linux. Le niveau de troll est vraiment impressionant…

        • [^] # Re: systemd

          Posté par  . Évalué à 3.

          Le script rc ne ressemble pas du tout à du systemd : par exemple, de la configuration est accédée par rc.subr, ce qui n'est pas le cas dans systemd où toute la configuration pour le service est soit dans l'initscript soit gérée par le service dans sa propre configuration.

          Grande nouvelle. systemd ne lit pas la conf de l'unit. ça c'est fort. Dans ce cas, pourquoi écrire un unit s'il n'est pas lu ?

      • [^] # Re: systemd

        Posté par  . Évalué à 3.

        Documentation :
        aucune.

        Ça c'est faux. On peut reprocher beaucoup de choses à systemd mais pas son absence de doc.

        Tout est dans man systemd.unit.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Upstart et portages

    Posté par  . Évalué à 5.

    Upstream est ouvert aux portages. D'ailleurs c'est en cours pour BSD.
    http://blog.surgut.co.uk/2013/11/libnih-upstart-dependency-ported-to.html

    Ça pourrait éventuellement jouer (ou pas) sur la décision que prendra (ou pas) le comité technique de Debian.

    • [^] # Re: Upstart et portages

      Posté par  (site web personnel) . Évalué à 2.

      Il reste plus qu'à porter sur le hurd et minix :)

      Ceci dit, j'ai regardé un peu le code de upstart en vue de voir si il serait dur de faire une couche de compatibilité pour l'activation des sockets ( entre systemd et upstart vu que ça semble presque compatible, ça passe un FD via une variable d'env ), et j'ai un peu sourcillé de voir la macro NIH_MUST, une macro qui tente une fonction jusqu'à ce que ça réussisse ( cf http://ifdeflinux.blogspot.fr/2012/05/quick-libnih-tutorial.html ).

      Je sais pas si c'est vachement bien foutu, ou juste vachement bourrin (ou les deux).

  • # Quelques alternatives

    Posté par  . Évalué à 3. Dernière modification le 03 décembre 2013 à 22:16.

    Si jamais ça peut servir à d'autres…

    • [^] # Re: Quelques alternatives

      Posté par  . Évalué à 4.

      N.B. sur le même thème, je suis à la recherche du document "SpeedingUpLinuxWithPardus.html" (qui semble ne plus exister nulle part), si quelqu'un en a une copie :)
      Il expliquait de manière très intéressante les choix de Pardus concernant leur système de boot original (et tout en Python :)

      • [^] # Re: Quelques alternatives

        Posté par  . Évalué à 7. Dernière modification le 03 décembre 2013 à 22:54.

        Il suffit de demander à archive.org

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: Quelques alternatives

        Posté par  . Évalué à 0.

        All Perl, sed, awk, grep, cut, find, and advanced shell dependencies are removed from base system.

        Oh que j'aime lire ça ^ - quitte à me prendre un -10 par les mongueurs de Perl.

        Parce que finalement hormis la syntaxe des scripts qui diffère de 3 caractères et le fait de tout ranger dans un script ou plusieurs dossiers je ne saisis pas les subtiles différences entre les 3 systèmes d'init présentés. Il s'agit de scripts shell en gros. Seul Mudur pour Pardus me semble avoir une approche réellement différente en étant pur Python et en virant un maximum de dépendances.

        • [^] # Re: Quelques alternatives

          Posté par  . Évalué à 3.

          Oh que j'aime lire ça ^ - quitte à me prendre un -10 par les mongueurs de Perl.

          N'aie crainte, avec les perlistes c'est TIMTOWDY, et c'est pourquoi ils sont même capables d'écrire du python si besoin est. La preuve :

          #!/usr/bin/perl 

use Acme::Pythonic;

my @words = ("hello","world!")

for my $word in @words:
    print($word, " ")

my $flag = 1

if $flag:
    print("flag is active")
else:
    pass

      • [^] # Re: Quelques alternatives

        Posté par  (site web personnel) . Évalué à 3.

        helas, les budgets pour pardus ont disparus, si je me souviens bien après avoir discuté sur irc avec un professeur d'istanbul, membre du projet.

    • [^] # Re: Quelques alternatives

      Posté par  . Évalué à 1. Dernière modification le 05 décembre 2013 à 11:28.

      Bonjour à tous,

      quid de s6
      http://www.skarnet.org/software/s6/

      faisant partie de skarnet
      http://www.skarnet.org/software

      hugh (dirait l'indien)

  • # Upstart

    Posté par  . Évalué à 9. Dernière modification le 03 décembre 2013 à 23:53.

    Il est (ou a été) utilisé par défaut par de nombreuses distributions : Ubuntu, Red Hat Entreprise Linux, Fedora et Chrome OS.

    Faut le dire très vite.

    RHEL utilise un gros script /etc/rc.sysvinit au démarrage qui se charge de monter les fs, définir le hostname, l'équivalant du niveau rcS de Debian quoi… Après il appelle upstart pour trois merdes (le spash screen, l'initialisation des tty…) puis utilise la couche de compatibilité SysV d'upstart pour lancer les services de /etc/init.d

    Bref il utilise Upstart de la façon la plus inutile qu'il soit, su RHEL 7 fait pareil avec SystemD, ça promet !

    Bon faut dire après qu'ils sont bloqué avec la version 0.6 d'Upstart qui n'offre même pas de façon propre d'activer/désactiver les services (un comble pour un gestionnaire de services)

    • [^] # Re: Upstart

      Posté par  (site web personnel) . Évalué à 1.

      Surtout que Fedora ne l'utilise plus depuis la version 15 : http://fedoraproject.org/wiki/Features/systemd. Le site officiel d'Upstart n'est pas non plus à jour à ce sujet : http://upstart.ubuntu.com/

      • [^] # Re: Upstart

        Posté par  . Évalué à 3.

        Il est (ou a été) utilisé

    • [^] # Re: Upstart

      Posté par  (site web personnel) . Évalué à 7.

      Bref il utilise Upstart de la façon la plus inutile qu'il soit, si RHEL 7 fait pareil avec SystemD, ça promet !

      C'est peu probable, vu que la quasi totalité des services sous Fedora depuis la version 18 (la version sur laquelle est basée RHEL si je ne me trompe pas) n'utilisent plus de script d'init mais uniquement les units systemd.

      PS: Arrêtez d'écrire systemd n'importe comment s'il vous plaît.

    • [^] # Re: Upstart

      Posté par  (site web personnel) . Évalué à 3.

      Je pense que pour rhel6, l'idée était d'intégrer upstart parce que Fedora a pris upstart, et si l'intégration avait été poussé plus loin, ça aurait été bien mieux.

      Mais même Canonical n'avait pas vraiment poussé upstart et apparmor à l'époque ( vers la 10.04 ), ce qui m'a un peu déçu. Je comprends qu'ils ont pas le staff requis pour ça, mais ça a rajouté une raison de plus pour moi de prendre ce qu'ils disent avec des pincettes. Dieu merci, maintenant, ça semble se faire, même si il reste encore pas mal de boulot.

  • # DMD

    Posté par  . Évalué à 4.

    Depuis le 3 Dec 2013, il y a aussi GNU dmd le nouveau système d'initialisation fonctionnant avec GNU guix le nouveau gestionnaire de paquets (GNU system).

    GNU dmd is a dependency-based service manager meant to be used as the init system in GNU. It is written in Guile Scheme.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.