• [^] # Re: systemd

    Posté par . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). É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