Évolutions techniques de systemd

Posté par . Modéré par baud123. Licence CC by-sa
140
2
août
2011
Linux

LinuxFr.org a déjà publié quelques articles à propos de systemd, sans entrer trop dans les détails des améliorations techniques.

On trouve en particulier un entretien avec son auteur, Lennart Poettering, et un journal contestant la qualité et les dépendances du code.

L’arrivée de systemd provoque pas mal de remous, justifiés ou non. On peut citer l’objectif « Linux only » affiché par l’auteur, les multiples dépendances et en particulier celle de D-Bus, la personnalité de l’auteur et la qualité de ses réalisations précédentes, le périmètre de responsabilité de systemd (gdm) et probablement de nombreux autres points.

Cet article a pour objectif de passer en revue les évolutions techniques et les objectifs de systemd. Les autres questions citées ci‐dessus ne sont pas injustifiées (en tout cas, pas toutes), mais sont en dehors du périmètre fixé.

L’article se base essentiellement sur les présentations de Lennart Poettering publiées sur son site en particulier, certains paragraphes sont des traductions un peu condensées de sa présentation initiale.

Merci aux relecteurs : Davy, Spack, npa.

Sommaire

  • État des lieux
  • Performances
  • Gains fonctionnels
  • État des lieux

    Processus de PID 1

    Sur un système UNIX, le tout premier processus (PID 1) a un rôle particulier :

    1. c’est le seul qui est lancé par le noyau ; il doit donc assurer toute l’initialisation du système, le lancement des différents services et des systèmes permettant la connexion des utilisateurs ;
    2. dans la hiérarchie des processus tournant sur le système, lorsqu’un processus devient orphelin, la norme et l’usage veut qu’il soit attaché au processus de PID 1. Dans ce cas lorsque le processus se termine, c’est au PID 1 qu’il revient de lire le code de retour du processus zombie, avant que le système puisse libérer certaines ressources associées.

    L’évolution de l’informatique fait que le système évolue au fil du temps (ajout ou suppression de périphériques, lancement ou arrêt de services). Nous avons aussi des plantages de services ou des mises à jour.

    SysVinit

    Sous GNU/Linux, c’est généralement SysVinit, le système d’initialisation hérité d’UNIX Système V qui assure ce rôle, remplacé par Upstart dans plusieurs distributions.

    Hélas, SysVinit reste très basique, peu performant et sujet à de nombreux problèmes. Il n’est pas très adapté à toutes les évolutions modernes que connaît Linux.

    Changement dynamique du matériel et du logiciel

    Pour l’instant, ces modifications du système sont réalisées par des scripts lancés dynamiquement, généralement par root ou par un autre service (udev) ; mais si un système moderne était chargé de maintenir le système opérationnel, il devrait aussi s’occuper de ces modifications.

    Le fichier « /etc/inittab » permet historiquement d’assurer une forme basique de suivi des services et de définir plusieurs modes de fonctionnement ; mais dans les distributions actuelles, il est terriblement en perte de vitesse, toute la charge fonctionnelle étant déplacée dans les scripts SysVinit.

    Performances

    Lennart Poettering constate que le système d’initialisation SysV est vieux et lent. Pour améliorer les choses, il faudrait :

    • démarrer moins de choses ;
    • démarrer les choses en parallèle lorsque c’est possible.

    Pour démarrer moins de choses, une solution éprouvée est de retarder le démarrage de certains services jusqu’au moment où ils sont effectivement nécessaires (démarrage à la demande). Par exemple, bluetoothd est inutile tant qu’aucun périphérique Bluetooth n’est présent et qu’aucune application ne s’adresse à lui via D-Bus. Pareillement, CUPS ne sert que pour configurer une imprimante ou pour imprimer, actions qui surviennent rarement dans les premières minutes de démarrage d’un système. Même SSH pourrait n’être démarré qu’au moment où arrive la première connexion entrante.

    Pour démarrer les services en parallèle, il est nécessaire de tout lancer en même temps, et non de démarrer les services un à un comme le fait SysVinit.

    Quasiment tous les systèmes qui tentent de paralléliser le démarrage de plusieurs services se servent d’un arbre de dépendances permettant d’imposer le lancement des services indispensables au démarrage d’un service donné. Avahi nécessite D-Bus, donc le système démarre D-Bus et attend qu’il soit prêt avant de lancer Avahi.

    Paralléliser le lancement des services sur sockets (AF_UNIX)

    AB (B est dépendant de A)

    Cette approche des dépendances est coûteuse en temps, et contournable. Lorsqu’une dépendance existe, le second service (B) n’a pas réellement besoin que l’initialisation du premier service (A) soit terminée pour commencer à démarrer (charger son code en mémoire vive, lire son fichier de configuration…).

    En poussant le raisonnement plus loin, la seule chose nécessaire pour ne pas provoquer d’erreurs lors du lancement du second service (B) est que l’interface du premier (A) soit en place et capable de temporiser les requêtes reçues. Le second service (B) pourra alors s’y connecter sans recevoir d’erreur. Le premier service (A) traitera les requêtes lorsqu’il sera prêt.

    Dans le cas de services répondant sur des sockets UNIX (AF_UNIX, présents comme des fichiers de type « s » sur le disque), la simple existence du socket est suffisante. Le noyau s’assure que les données reçues sont mises en attente ou que l’émetteur est bloqué tant qu’elles ne sont pas lues. Les services utilisateurs du démon de journalisation d’événements syslog ont besoin de se connecter à un socket appelé « /dev/log », ceux de CUPS utilisent « /var/run/cups/cups.sock », etc. Si les sockets correspondants existent, alors il est possible de lancer toutes les dépendances, et la synchronisation se fera toute seule au fur et à mesure que les services seront prêts et répondront aux requêtes reçues.

    Sur un système UNIX où les entrées‐sorties sont assimilées à des fichiers, il est très facile de créer ces sockets avant même de lancer le service associé.

    Supprimer les dépendances explicites entre les services

    Si la création des sockets est indépendante du lancement des services, le problème de dépendances disparaît. Dans une première phase, nous pourrions créer tous les sockets nécessaires au système, et dans un second temps, lancer tous les services en parallèle.

    Prenons l’exemple de Syslog. Dès l’instant où « /dev/log » est créé, il est possible de lancer des services qui vont envoyer leurs événements dans « /dev/log ». Ces messages seront mis en attente tant que Syslog ne sera pas prêt. Dès qu’il aura démarré, Syslog lira tous les messages reçus et assurera leur traitement.

    Démarrer moins de choses

    Ce principe permet également de faire du démarrage à la demande. Si personne ne s’adresse à un service, il est inutile de le lancer. À l’instar d’inetd (et de son remplaçant xinetd) ; nous pouvons attendre qu’un service ait reçu une demande de connexion pour le lancer. Pour les postes de travail qui impriment trois pages par semaine, CUPS est un bon candidat. Tant qu’aucune impression n’est lancée, aucune donnée n’arrive et le service CUPS n’a pas de raison d’être démarré.

    Un système plus résistant

    Nous trouvons un nouvel avantage à ce système de démarrage : une certaine forme de résistance aux crashs d’un service. Si votre service syslog se plante lamentablement, les données qui arrivent dans « /dev/log » sont mises en attente par le noyau. Lorsque syslog est relancé, aucun message n’est perdu (si ce n’est ceux qu’il a déjà lus et perdus lors de son crash), même si le temps de démarrage est important.

    De la même façon, en cas de redémarrage d’un service, par exemple suite à une mise à jour, aucun message n’est perdu.

    Services réseau (AF_INET, AF_INET6 et D-Bus)

    Sur un système moderne, les services ne se limitent pas à un socket, ils reçoivent des connexions via le réseau IP ou via D-Bus. Est‐ce que ce mécanisme est aussi adaptable à ce type d’interface ? La réponse est oui.

    D-Bus permet un mode « bus-activation » où un service est démarré par la réception d’un message lui étant destiné.

    Concernant le réseau IP, c’est exactement ce que propose inetd et ses successeurs depuis des années (en mode « wait »). Le socket réseau est créé par inetd. À la réception de données, le service est lancé déjà connecté au socket. La contrainte est que le service doit être capable de fonctionner sur un socket réseau déjà créé.

    Résumé et Interlude

    Par ce mécanisme, il est possible de démarrer tous les services en parallèle, sans aucun mécanisme de synchronisation. Il permet également de démarrer les services à la demande et non plus systématiquement.

    Ce système n’est pas nouveau, nous avons vu qu’inetd présentait déjà des aspects similaires. Apple a développé tous les points ci‐dessus dans son système Mac OS X, sous le nom de launchd. C’est cela qui permet à Mac OS X de démarrer très rapidement.

    Les systèmes de fichiers

    Le démarrage du système ne se limite pas au démarrage des services. La préparation des systèmes de fichiers est également une opération qui peut prendre beaucoup de temps. Il faut attendre que tous les périphériques listés dans « /etc/fstab » soient créés, que chaque système de fichiers soit vérifié avec fsck, que le système soit monté et éventuellement que les quotas soient contrôlés.

    Pour accélérer cela, Harald Hoyer a eu l’idée d’utiliser le système autofs en mode direct. De la même façon que pour les sockets, autofs permet de monter un pseudo système de fichiers à la place du système réel, et de ne basculer sur le vrai système qu’au moment où un accès est fait. Comme pour la création de sockets, le montage du pseudo système de fichiers est quasiment instantané.

    Si un accès est fait alors que le système de fichiers n’est pas prêt (fsck en cours, par exemple), alors le noyau bloque la requête (et celui qui l’a faite) jusqu’à ce que le système de fichiers soit disponible.

    Pour la racine (« / »), cela ne présente pas d’intérêt ; mais pour les grosses volumétries qui peuvent être montées sur « /home », ou pour des partitions de données qui ne sont pas nécessaires au démarrage du système, cela présente un gain important.

    L’intégration de autofs dans un système de démarrage peut faire peur à plus d’une personne. L’expérience montre que les processus bloqués par des fichiers qui ne sont pas disponibles peuvent être tués proprement, et qu’en cas d’erreur lors de la vérification du système de fichiers, il est possible de retourner une erreur au processus réclamant le fichier, de la même façon que cela se produit lorsqu’une partition tombe en erreur.

    Gains fonctionnels

    Avoir un petit PID utilisable

    Les scripts sont rapides à coder, mais lents à exécuter. Tout le système de démarrage SysVinit est basé sur des scripts qui lancent des commandes externes. D’après Lennart cette approche est condamnée à être lente. Sur son système, les scripts dans « /etc/init.d/ » appellent grep au moins 77 fois, awk l’est 92 fois, cut, 23 fois, et sed, 74 fois. À chaque appel, un processus doit être démarré, les bibliothèques résolues, la localisation initialisée, etc.. Après une manipulation de quelques octets, les données doivent être retournées à l’appelant via un descripteur de fichier et le processus est détruit. En outre, les scripts sont très sensibles à l’environnement et peu adaptés à la gestion des erreurs et des exceptions.

    Tous ces scripts, ne faisant pour beaucoup que des tâches triviales, et contenant beaucoup de code dupliqué, auraient plutôt leur place dans le processus d’initialisation ou dans l’un de ses sous‐programmes. Tout ré‐écrire en C n’est pas pertinent ; mais le système devrait être capable de gérer bien plus de choses par lui‐même, sans faire appel à des scripts.

    Une métrique intéressante est le PID du premier processus utilisable une fois le système démarré. Avec les noyaux actuels, cela donne une bonne idée du nombre de processus lancés. Amorcer le système, lancer un terminal, faire « echo $$ » : sous Linux, le PID est 1823, sous Mac OS X c’est 154.

    Suivre les processus

    Une grosse part du mécanisme qui démarre les services devrait être la supervision : surveiller les services, pouvoir les identifier, redémarrer ceux qui plantent, collecter les traces.

    Il devrait être capable de couper complètement un service. Cela semble facile mais est en réalité très difficile. Sous UNIX, un processus qui fait un double fork (le programme se relance lui‐même en tâche de fond) sort complètement de la supervision du processus qui l’a lancé. Prenons par exemple un script CGI lancé par un serveur Web. Lorsqu’il fait un double fork, il devient orphelin et est rattaché au processus de PID 1. L’arrêt du serveur Web ne le concerne pas, et aucun script système n’est en mesure de le retrouver automatiquement pour le couper.

    Pour résoudre ce problème, le noyau Linux implémente un mécanisme appelé cgroups (control groups) qui, comme son nom l’indique, permet de créer un groupe et d’y placer des processus. Tout processus créé au sein d’un cgroup y reste, résolvant ainsi notre problème de CGI fou. Les cgroups présentent un autre avantage (c’était leur objectif initial) : il est possible de placer certaines restrictions (processeur, mémoire, entrées‐sorties) afin de limiter la consommation d’un service dans sa globalité.

    Contrôler le contexte du service

    Un bon superviseur devrait également être capable de placer le service dans un environnement adapté et sécurisé. Jetez un coup d’œil aux scripts dans « /etc/init.d/ », tout le code dupliqué concerne le traitement des options, le changement d’utilisateur et de groupe, le réglage des paramètres de sécurité, la création d’un environnement avec une racine isolée (à l’aide de chroot), la création d’un fichier contenant le PID, retrouver le processus pour lui envoyer un signal. Le même code, légèrement différent, se répète de script en script. Tout cela gagnerait à être normalisé et mutualisé.

    Le système devrait permettre de régler les limites de ressources, la priorité, l’utilisateur et le groupe. Cela ne s’arrête pas là, le noyau Linux permet aussi de définir les capacités, les règles d’ordonnancement et d’entrées‐sorties, l’affinité avec les processeurs, supprimer l’accès en écriture à certaines partitions, et aussi tous les paramètres liés aux cgroups.

    Enfin, sous UNIX, tout processus a une sortie standard et une sortie d’erreur, qui sont la première source d’information en cas d’anomalie. Aujourd’hui, sur la majorité des distributions, ces données sont difficiles à récupérer, le système de démarrage devrait au contraire les conserver précieusement ; au moins en les redirigeant vers le service de journalisation des événements.

    Second interlude : Upstart et les autres systèmes

    Upstart est une grosse avancée par rapport à SysVinit. Il s’occupe du démarrage et de l’arrêt des services en fonction d’événements. Il gère tout un arbre de dépendances pour déterminer quoi démarrer et dans quel ordre, afin d’arriver à une situation cible. Malheureusement, cette gestion de dépendances demande de coder manuellement toutes les contraintes d’un service.

    Cela a plusieurs effets pervers :

    • en cas d’anomalie, bien malin est celui qui retrouvera ce qui s’est produit et dans quel ordre ;
    • le travail du système de démarrage a considérablement augmenté, puisqu’avant de démarrer quelque chose, il doit avoir constitué au moins une partie du graphe de dépendances ;
    • il ne permet pas de réduire le démarrage aux services strictement nécessaires. Si un service (A) peut être utilisé par un autre (B), alors il doit être marqué comme dépendant et démarré avant le second (AB).

    Lennart admet que certains de ces points sont en cours de correction, mais il s’agit de contournements du principe de fonctionnement d’Upstart.

    En dehors de SysVinit, Upstart et launchd (Mac OS X), un autre système mérite notre intérêt, c’est Solaris SMF. Il gère les dépendances entre les services, mais est très lié à Solaris et très complexe dans son fonctionnement (par exemple par son utilisation excessive de XML).

    Systemd

    L’implémentation

    Ce qui a été décrit ci‐dessus est implémenté dans un système appelé systemd qui est en cours d’adoption par plusieurs distributions GNU/Linux.

    Le fonctionnement de systemd est basé sur des unités (units) qui ont un nom et un type. Le nom correspond au nom du fichier décrivant l’unité.

    Les types sont :

    • service : les plus simples correspondent à des services. Peuvent être démarrés, coupés, redémarrés, reconfigurés (start/stop/restart/reload), comme on le fait habituellement avec les scripts dans /etc/init.d/ ;
    • socket : correspond à une socket, que ce soit de type UNIX, de type Internet, de type fichier ; chaque socket a un service correspondant ;
    • mount : un système de fichiers ; ces unités viennent en plus du fichier /etc/fstab qui est utilisé directement ;
    • swap : pour les partitions d’échange ;
    • automount : un système de fichiers monté à la demande ;
    • target : une macro‐unité qui permet de grouper plusieurs unités, par exemple multi-user.target ou bluetooth.target ;
    • snapshot : comme target, ce sont des unités qui peuvent être utilisées pour sauver l’état actuel des services et les restaurer par la suite, par exemple avant de passer en veille ;
    • device : un périphérique dans le système Linux ; peut être une source de dépendance via udev ;
    • timer : activations à la sauce cron, en fonction de la date ;
    • path : sert pour l’activation basée sur la présence ou la création de fichiers ou répertoires.

    Toutes ces unités peuvent avoir des dépendances (Requires) et des conflits (Conflicts) déclarés de façon explicite.

    Les bonus

    • Pour chaque service, il est possible de régler de nombreux paramètres : limites, répertoire racine (chroot), umask, priorité, paramètre « OOM killer » (out of memory), les classes et les priorités d’ordonnancement et d’entrées‐sorties, l’affinité processeur, l’utilisateur, les groupes, les répertoires accessibles et les modes d’accès, les capacités, le répertoire temporaire, le réglage des cgroups
    • Les flux stdout et stderr peuvent être redirigés vers le service de journalisation, vers « /dev/kmsg », vers un terminal ou vers un fichier.
    • Intégration de SELinux, des « TCP wrappers », des modules d’authentification PAM.
    • Chaque service a son propre cgroup.
    • Chaque connexion via un terminal est aussi placée dans son propre cgroup, ce qui permet de fermer complètement une session et d’isoler un peu mieux les utilisateurs (processeur, mémoire).
    • La syntaxe des fichiers de configuration suit celle bien connue des fichiers « .desktop ».
    • Le système est compatible avec les anciens scripts SysVinit. Les informations LSB et chkconfig (de Red Hat) ainsi que celles de Debian et d’OpenSUSE sont utilisées lorsqu’elles sont disponibles. Sinon, l’ordre de démarrage dans « /etc/rc.d/ » est utilisé. systemd est également capable de lire le fichier PID pour retrouver un service. Ces données permettent d’émuler une configuration classique SysVinit, facilitant la transition.
    • Le fichier « /etc/fstab » est également lu comme s’il s’agissait d’un fichier de configuration de systemd.
    • Les fichiers natifs systemd masquent ces émulations, permettant de faire des paquets compatibles avec les deux systèmes, le nouveau masquant l’ancien si nécessaire.
    • Il existe un système de modèles pour éviter de dupliquer une configuration (par exemple, pour les  6 getty des terminaux virtuels habituellement lancés).
    • systemd fourni une couche de compatibilité avec « /dev/initctl » permettant d’utiliser les vieux binaires, tels que shutdown ou reboot. Les ordres sont transmis à systemd via D-Bus. Il prend en charge également kexec qui permet de relancer le noyau Linux.
    • Il gère utmp et wtmp, les journaux système enregistrant les connexions.
    • Chaque processus lancé est tracé par son heure de démarrage, de fin, son PID et son code de retour ; permettant d’analyser les anomalies.
    • systemd est capable de se ré‐exécuter lui‐même, afin de faire une mise à jour, ou de passer d’un processus provenant d’un « RAM‐disque » d’amorçage (initrd) au système final. Tout l’état courant est migré d’un processus à l’autre.
    • La mise en place des systèmes de fichiers virtuels est directement prise en charge par systemd (/proc, /sys, /dev), binfmt_misc et HugeTBLfs sont gérés via autofs, ce qui évite d’avoir à les configurer en root ou à charger le module correspondant.
    • De nombreuses petites fonctions sont prises en charge directement sans passer par le lancement d’un script : définir le nom de la machine, sauver / restaurer les données aléatoires, initialiser la localisation, nettoyer les répertoires temporaires, configurer la console, le clavier, charger des modules. Cela a pour conséquence d’unifier ces fichiers de configuration sur toutes les distributions utilisant systemd.
    • Il existe un mode de démarrage interactif qui permet de confirmer chaque lancement de service en passant au noyau le paramètre « systemd.confirm_spawn=1 ».
    • systemd gère le readahead qui permet d’optimiser les lectures disque au démarrage en pré‐chargeant les blocs qui vont être nécessaires par la suite (en se basant sur un enregistrement d’un démarrage précédent).

    L’administration

    L’administration se fait par l’intermédiaire de quelques commandes dédiées et quelques fichiers de configuration qui sont documentés via une vingtaine de pages de manuel. Un certain nombre de pages liées à l’utilisation de systemd sont également modifiées.

    Définition d’un service

    Lorsque l’on regarde les scripts d’initialisation d’un service contenu dans le dossier « /etc/init.d », on constate que la plupart des scripts se ressemblent. L’information utile (programme à lancer, description du service, dépendances, niveaux de lancement) est complètement perdue dans le bruit généré par le code de gestion (création d’un fichier PID, s’assurer que le programme ne tourne pas déjà, gestion des cas d’utilisation…).

    Systemd intègre toutes ces notions redondantes et permet à l’administrateur de définir un service de façon simple.

    [Unit]
    Description=ABRT Automated Bug Reporting Tool
    After=syslog.target
    
    [Service]
    Type=dbus
    BusName=com.redhat.abrt
    ExecStart=/usr/sbin/abrtd -d -s
    
    [Install]
    WantedBy=multi-user.target
    

    Ici, est défini le service ABRT. Comme on le voit, la définition est assez simple :

    • le service doit être lancé après syslog ;
    • il s’agit d’un service D-Bus répondant au nom « com.redhat.abrt » ;
    • la commande à exécuter est : « /usr/sbin/abrtd -d -s » ;
    • le service doit être exécuté lorsqu’on choisi un environnement cible multi‐utilisateur (le mode de fonctionnement habituel).

    Regardons un autre exemple ressemblant un peu plus à ce que l’on a l’habitude de voir avec les scripts SysVinit :

    [Unit]
    Description=Command Scheduler
    After=syslog.target
    
    [Service]
    EnvironmentFile=/etc/sysconfig/crond
    ExecStart=/usr/sbin/crond -n $CRONDARGS
    
    [Install]
    WantedBy=multi-user.target
    

    Il est toujours possible de définir un fichier contenant les paramètres à passer au service :

    $ cat /etc/sysconfig/crond 
    ## Settings for the CRON daemon.
    ## CRONDARGS= :  any extra command-line startup arguments for crond
    CRONDARGS=
    

    Les fichiers de définition peuvent être trouvés dans les dossiers « /etc/systemd/ » et « /lib/systemd/ ». Le premier correspond à la configuration faite par l’administrateur, et le second aux fichiers livrés par la distribution.

    Gestion des services

    Avec systemd, la gestion des services se fait maintenant par l’utilitaire systemctl.

    Grâce à ce dernier, il est possible de lister toutes les unités présentes sur le système. Les commandes suivantes sont exécutées sur une distribution Fedora 15 :

    $ systemctl list-units
    NIT                      LOAD   ACTIVE SUB       JOB DESCRIPTION
    dev-hugepages.automount   loaded active waiting       Huge Pages File System Automount Point
    dev-mqueue.automount      loaded active waiting       POSIX Message Queue File System Automount Point
    proc-sys...misc.automount loaded active running       Arbitrary Executable File Formats File System Automount Point
    sys-kern...ebug.automount loaded active waiting       Debug File System Automount Point
    sys-kern...rity.automount loaded active waiting       Security File System Automount Point
    sys-devi...d-card0.device loaded active plugged       N10/ICH 7 Family High Definition Audio Controller
    sys-devi...et-eth0.device loaded active plugged       BCM4313 802.11b/g LP-PHY
    sys-devi...net-em2.device loaded active plugged       RTL8101E/RTL8102E PCI Express Fast Ethernet controller
    sys-devi...da-sda1.device loaded active plugged       Hitachi_HTS725025A9A364
    -.mount                   loaded active mounted       /
    boot.mount                loaded active mounted       /boot
    home-spack-.gvfs.mount    loaded active mounted       /home/spack/.gvfs
    home.mount                loaded active mounted       /home
    media.mount               loaded active mounted       Media Directory
    mcelog.service            loaded active running       Machine Check Exception Logging Daemon
    mdmonitor.service         loaded active running       LSB: Start and stop the MD software RAID monitor
    netfs.service             loaded active exited        LSB: Mount and unmount network filesystems.
    NetworkManager.service    loaded active running       Network Manager
    nfslock.service           loaded active running       LSB: Start up the NFS file locking sevice
    ntpd.service              loaded active running       Network Time Service
    ntpdate.service           loaded failed failed        Set time via NTP
    udev.service              loaded active running       udev Kernel Device Manager
    dbus.socket               loaded active running       D-Bus System Message Bus Socket
    syslog.socket             loaded active running       Syslog Socket
    systemd-initctl.socket    loaded active listening     /dev/initctl Compatibility Named Pipe
    systemd-logger.socket     loaded active running       Stdio Syslog Bridge Socket
    systemd-shutdownd.socket  loaded active listening     Delayed Shutdown Socket
    udev.socket               loaded active running       udev Kernel Device Manager Socket
    sockets.target            loaded active active        Sockets
    sound.target              loaded active active        Sound Card
    swap.target               loaded active active        Swap
    sysinit.target            loaded active active        System Initialization
    syslog.target             loaded active active        Syslog
    time-sync.target          loaded active active        System Time Synchronized
    systemd-...ead-done.timer loaded active elapsed       Stop Read-Ahead Data Collection 10s After Completed Startup
    systemd-...es-clean.timer loaded active waiting       Daily Cleanup of Temporary Directories
    

    L’affichage a été réduit mais présente les différents éléments pris en compte par systemd. On retrouve donc les différentes unités précédemment listées.

    Vous constaterez que le service « ntpdate.service » a échoué. Pour en savoir plus, nous pouvons utiliser la commande systemctl suivie de l’argument « status » et du nom de notre service :

    $ systemctl status ntpdate.service
    ntpdate.service - Set time via NTP
    	  Loaded: loaded (/lib/systemd/system/ntpdate.service)
    	  Active: failed since Mon, 01 Aug 2011 16:01:49 +0200; 1h 58min ago
    	 Process: 741 ExecStart=/etc/init.d/ntpdate start (code=exited, status=1/FAILURE)
    	  CGroup: name=systemd:/system/ntpdate.service
    

    On voit alors la commande exécutée et le code de retour renvoyé par le service : 1. Un coup d’œil au fichier « /var/log/messages » nous en dira plus :

    # grep ntpdate /var/log/messages
    Aug  1 16:01:49 spiro ntpdate[1654]: Can't find host 0.fedora.pool.ntp.org: Name or service not known (-2)
    Aug  1 16:01:49 spiro ntpdate[1654]: Can't find host 1.fedora.pool.ntp.org: Name or service not known (-2)
    Aug  1 16:01:49 spiro ntpdate[1654]: Can't find host 2.fedora.pool.ntp.org: Name or service not known (-2)
    Aug  1 16:01:49 spiro ntpdate[1654]: Can't find host 3.fedora.pool.ntp.org: Name or service not known (-2)
    Aug  1 16:01:49 spiro ntpdate[1654]: no servers can be used, exiting
    Aug  1 16:01:49 spiro systemd[1]: ntpdate.service: main process exited, code=exited, status=1
    Aug  1 16:01:49 spiro systemd[1]: Unit ntpdate.service entered failed state.
    

    À l’aide de systemctl, il est bien sûr possible de démarrer, stopper et redémarrer les services. Voici, par exemple, comment l’on redémarre le service de prise en charge du Bluetooth :

    # systemctl restart bluetooth.service
    

    cgroups

    Nous avons vu que systemd place chaque service dans un groupe distinct. Il serait donc intéressant d’identifier les différents groupes et les processus qu’ils contiennent.
    Pour cela, deux possibilités. Utiliser l’utilitaire ps ou l’outil maison de systemd : « systemd-cgls ».

    $ ps waxf -eo 'user,pid,cgroup,command'
    USER       PID CGROUP                      COMMAND
    root         1 name=systemd:/system        /sbin/init
    root       367 cpu:/system/systemd-logger. /lib/systemd/systemd-logger
    root       390 cpu:/system/udev.service;na /sbin/udevd
    root       544 cpu:/system/udev.service;na  \_ /sbin/udevd
    root      1450 cpu:/system/udev.service;na  \_ /sbin/udevd
    root       685 cpu:/system/abrtd.service;n /usr/sbin/abrtd -d -s
    root       694 cpu:/system/crond.service;n /usr/sbin/crond -n
    root       717 cpu:/system/rsyslog.service /sbin/rsyslogd -n -c 5
    root      1086 cpu:/system/autofs.service; automount --pid-file /var/run/autofs.pid
    root      1127 cpu:/system/prefdm.service; /usr/sbin/gdm-binary -nodaemon
    root      1135 cpu:/system/prefdm.service;  \_ /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1
    root      1139 cpu:/system/prefdm.service;      \_ /usr/bin/Xorg :0 -background none -verbose -auth /var/run/gdm/auth-for-gdm-GWn7Er/database -n
    root      1352 name=systemd:/user/spack/1       \_ pam: gdm-password
    spack     1374 name=systemd:/user/spack/1           \_ gnome-session
    spack     1526 name=systemd:/user/spack/1               \_ /usr/libexec/gnome-settings-daemon
    spack     1562 name=systemd:/user/spack/1               \_ /usr/bin/gnome-shell
    spack     1786 name=systemd:/user/spack/1               |   \_ gnome-terminal
    spack     1791 name=systemd:/user/spack/1               |       \_ gnome-pty-helper
    spack     1792 name=systemd:/user/spack/1               |       \_ bash
    spack     1810 name=systemd:/user/spack/1               |       \_ bash
    spack     1823 name=systemd:/user/spack/1               |           \_ ps waxf -eo user,pid,cgroup,command
    spack     1569 name=systemd:/user/spack/1               \_ gnome-power-manager
    spack     1574 name=systemd:/user/spack/1               \_ nm-applet
    spack     1575 name=systemd:/user/spack/1               \_ abrt-applet
    spack     1578 name=systemd:/user/spack/1               \_ gnome-screensaver
    root      1151 cpu:/system/getty@.service/ /sbin/agetty tty2 38400
    root      1152 cpu:/system/getty@.service/ /sbin/agetty tty6 38400
    root      1155 cpu:/system/getty@.service/ /sbin/agetty tty4 38400
    root      1159 cpu:/system/getty@.service/ /sbin/agetty tty3 38400
    root      1160 cpu:/system/getty@.service/ /sbin/agetty tty5 38400
    

    $ systemd-cgls 
    ├ user
    │ └ spack
    │   └ 1
    │     ├ 1352 pam: gdm-password
    │     ├ 1374 gnome-session
    │     ├ 1383 dbus-launch --sh-syntax --exit-with-session
    │     ├ 1384 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
    │     ├ 1445 /usr/libexec/gvfsd
    │     ├ 1521 /usr/libexec/gconfd-2
    │     ├ 1526 /usr/libexec/gnome-settings-daemon
    │     ├ 1529 /usr/bin/pulseaudio --start
    │     ├ 1562 /usr/bin/gnome-shell
    │     ├ 1569 gnome-power-manager
    │     ├ 1574 nm-applet
    │     ├ 1575 abrt-applet
    │     ├ 1578 gnome-screensaver
    │     ├ 1583 /usr/libexec/dconf-service
    │     ├ 1786 gnome-terminal
    │     ├ 1791 gnome-pty-helper
    │     ├ 1792 bash
    │     └ 1809 systemd-cgls
    └ system
      ├ 1 /sbin/init
      ├ getty@.service
      │ ├ tty5
      │ │ └ 1160 /sbin/agetty tty5 38400
      │ ├ tty3
      │ │ └ 1159 /sbin/agetty tty3 38400
      │ ├ tty4
      │ │ └ 1155 /sbin/agetty tty4 38400
      │ ├ tty6
      │ │ └ 1152 /sbin/agetty tty6 38400
      │ └ tty2
      │   └ 1151 /sbin/agetty tty2 38400
      ├ prefdm.service
      │ ├ 1127 /usr/sbin/gdm-binary -nodaemon
      │ ├ 1135 /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1
      │ ├ 1139 /usr/bin/Xorg :0 -background none -verbose -auth /var/run/gdm/auth-for-gdm-GWn7Er/database -nolisten tcp vt1
      │ └ 1363 /usr/bin/gnome-keyring-daemon --daemonize --login
      ├ autofs.service
      │ └ 1086 automount --pid-file /var/run/autofs.pid
      ├ dbus.service
      │ ├  707 /bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation
      │ ├  720 /usr/libexec/polkit-1/polkitd
      │ ├  750 /usr/sbin/modem-manager
      │ ├  816 /usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -B -u -f /var/log/wpa_supplicant.log -P /var/run/wpa_supplic...
      │ ├ 1037 /usr/libexec/colord
      │ ├ 1282 /usr/libexec/udisks-daemon
      │ ├ 1283 udisks-daemon: not polling any devices
      │ ├ 1288 /usr/libexec/upowerd
      │ └ 1559 /usr/libexec/packagekitd
      ├ crond.service
      │ └ 694 /usr/sbin/crond -n
      ├ rsyslog.service
      │ └ 717 /sbin/rsyslogd -n -c 5
      ├ abrtd.service
      │ └ 685 /usr/sbin/abrtd -d -s
      ├ home.mount
      ├ boot.mount
      ├ fsck@.service
      ├ udev.service
      │ ├  390 /sbin/udevd
      │ ├  544 /sbin/udevd
      │ └ 1450 /sbin/udevd
      ├ systemd-logger.service
      │ └ 367 /lib/systemd/systemd-logger
      └ media.mount
    

    Vous l’aurez constaté, systemd gère non seulement les ressources du système, mais aussi celles des utilisateurs.

    Écrire un service

    L’utilisation de systemd simplifie un certain nombre de choses dans l’écriture d’un service :

    • il n’est plus nécessaire de se relancer pour passer en arrière‐plan (fork), et encore moins de le faire deux fois (double‐fork) ;
    • il n’est plus nécessaire d’implémenter de mécanisme pour changer d’utilisateur, pour modifier les privilèges, pour faire un chroot ; tout cela étant pris en charge par systemd ;
    • avec les cgroups, il n’est plus nécessaire d’écrire un fichier PID permettant de retrouver le service via son identifiant de processus ;
    • pour les cas simples, il n’est plus nécessaire de mettre en place une interface vers le service de journalisation des événements, les sorties classiques étant gérées comme des journaux (cela ne permet toutefois pas de spécifier la sévérité) ;
    • il n’est plus nécessaire de configurer et de créer les sockets.

    Ces recommandations sont très semblables à celles d’Apple pour utiliser launchd. Pour les services écrits de façon classique, systemd dispose de mécanismes de compatibilité afin de pouvoir les démarrer selon l’ancienne mode. Enfin, il est tout à fait possible — et recommandé — d’écrire des services qui fonctionnent dans tous les modes (autonomes ou systemd), évitant de produire une version spéciale ou de créer une branche.

    systemd vient avec un kit d’intégration en C, qui facilite l’intégration dans un service. Lennart a publié deux notes de documentation et une page de manuel très complète :

    Conclusion

    Au travers de cet article vous a été présenté un sous‐ensemble des fonctionnalités offertes par systemd. Il repense totalement la gestion des processus des systèmes basés sur le noyau Linux, et utilise pleinement les technologies offertes par ce dernier.

    Plusieurs distributions intègrent ou vont intégrer systemd. D’après l’article concernant systemd sur Wikipédia, il est utilisé depuis Fedora 15, et est optionnel dans Fedora 14. openSUSE prévoyait de l’intégrer dans la version 11.4, mais cela semble être repoussé à la 12.1. Mandriva 2011 est prévue avec. Arch Linux a un paquet expérimental. Debian a un paquet dans « unstable » et devrait permettre de choisir un système ou l’autre dans une prochaine version. Gentoo rend systemd accessible dans « testing ». Le grand absent est Ubuntu, qui a beaucoup investi dans Upstart et n’a pas manifesté, pour l’instant, de volonté de passer à systemd (bien qu’un début d’intégration existe).

    Cet outil à tout faire, semble faire un pied de nez à la philosophie d’UNIX en combinant plusieurs fonctions en un seul programme. D’un autre côté, le système de démarrage actuel montre ses limites.

    La gestion de l’initialisation est très importante pour le système. On peut donc se demander s’il est judicieux d’inclure tant de fonctionnalités dans un programme critique ? Cependant, avec les contraintes de performances et la complexité des systèmes actuels, n’est‐ce pas un mal nécessaire pour gérer efficacement les processus exécutés sur nos systèmes ?

  • # Merci pour le journal

    Posté par . Évalué à  10 .

    Je ne dirais qu'une chose: on croirait du patrick_g!

    • [^] # Re: Merci pour le journal

      Posté par (page perso) . Évalué à  10 .

      je ne trouve pas de qualificatif plus moulesque... bravo pour l'article !

      ps: a quand le prix Patrick_G de la dépêche de l'année ?

      Alexandre COLLIGNON

      • [^] # Re: Merci pour le journal

        Posté par . Évalué à  10 .

        +1
        bonne idée de nom, "le prix patrick_g", et avec son pseudo en plus ça résonnerai à l'extérieur :p

    • [^] # Re: Merci pour le journal

      Posté par . Évalué à  9 .

      SysVinit reste très basique, peu performant et sujet à de nombreux problèmes. Il n’est pas très adapté à toutes les évolutions modernes que connaît Linux

      Mouhai, enfin, affirmer ça sans exemples c'est un peu rude, quant même. Alors un exemple : mettons que "l'évolution moderne" signifie "bureau" puisque le bureau est ce qui apporte le plus de contraintes et de difficultés (dixit Linus T himself), regardons un exemple dans l'exemple : NetworkManager.
      ça démarre le réseau lorsque le bureau est prêt. Très bien, très desktop (et les admins serveurs n'ont qu'à savoir faire ou ...). Mais avahi-daemon, exemple dans l'exemple, lui, ne serait il pas logique qu'il démarre aussi après le bureau, du coup ?

      Et c'est aussi là que systemD est intéressant (malgré le troll avahi) : ne pas windozé linux, ne pas lancer le bureau avant tout, dans tout les cas (ce que ferait une évolution "bêtement basique") mais proposer une réelle solution globale cohérente (et les admins, ils n'ont qu'à savoir faire, bis)

      moinssage

    • [^] # Re: Merci pour le journal

      Posté par (page perso) . Évalué à  2 .

      Je plussoie vigoureusement un article de cette qualité. L'analogie avec la production de Patrick_G est évidente.

      Bravo aux individus génétiquement modifiés disposant du temps nécessaire pour écrire de tels papiers (et accessoirement, "please die in a fire" :-)

    • [^] # Re: Merci pour le journal

      Posté par . Évalué à  2 .

      Entièrement d'accord. Je ne m'étais jamais vraiment intéressé à systemd, et bien c'est fait.

  • # localisation

    Posté par . Évalué à  10 .

    Est-ce qu'il est prévu la localisation des descriptions des services pour les commandes genre systemctl list-units ?

    Je sais que tout le monde cause anglais, mais en fait, non.

    • [^] # Re: localisation

      Posté par . Évalué à  6 .

      Oui, il est prévu « à terme » de supporter la localisation de la description des services.

      La réponse datant d'octobre 2010, je ne sais pas si cela est déjà implémenté.

      • [^] # Re: localisation

        Posté par . Évalué à  9 .

        D'après le lien ci-dessus :
        > the longer term plan is to support translations for the descriptions the same way as .desktop files have them.

        Ce qui veut dire que les traductions seront DANS les fichiers .service, vu que c'est comme ça que c'est fait avec les .desktop. Du coup, comme pour les .desktop, on risque de se retrouver avec, pour chaque valeur traduisible, un truc du genre :

        Name=PulseAudio Sound System
        Name[as]=PulseAudio শব্দ ব্যৱস্থা
        Name[bn_IN]=PulseAudio শব্দ ব্যবস্থা
        Name[ca]=Sistema de so PulseAudio
        Name[cs]=Zvukový systém PulseAudio
        Name[de]=PulseAudio Sound System
        Name[de_CH]=PulseAudio Sound System
        Name[es]=Sistema de Sonido PulseAudio
        Name[fi]=PulseAudio-äänijärjestelmä
        Name[fr]=Système de son PulseAudio
        Name[gu]=PulseAudio સાઉન્ડ સિસ્ટમ
        Name[hi]=पल्सऑडियो ध्वनि तंत्र
        Name[hu]=PulseAudio hangrendszer
        Name[it]=Sistema sonoro PulseAudio
        Name[kn]=PulseAudio ಧ್ವನಿ ವ್ಯವಸ್ಥೆ
        Name[ml]=PulseAudio സൌണ്ട് സിസ്റ്റം
        Name[mr]=PulseAudio आवाज प्रणाली
        Name[nl]=PulseAudio geluidssysteem
        Name[or]=PulseAudio ଧ୍ୱନି ତନ୍ତ୍ର
        Name[pa]=ਪਲਸਆਡੀਓ ਸਾਊਂਡ ਸਿਸਟਮ
        Name[pl]=System dźwięku PulseAudio
        Name[pt]=Sistema de Som PulseAudio
        Name[pt_BR]=Sistema de som PulseAudio
        Name[sr]=PulseAudio звучни систем
        Name[sr@latin]=PulseAudio zvučni sistem
        Name[ta]=பள்ஸ் ஆடியோ ஒலி கணினி
        Name[te]=PulseAudio శబ్దపు సిస్టమ్
        Name[uk]=Звукова система PulseAudio
        Name[zh_CN]=PulseAudio 声音系统
        

        Est-ce qu'on perd pas un peu l'avantage du côté clair et concis qu'on semblait avoir gagné ?

        • [^] # Re: localisation

          Posté par . Évalué à  2 .

          Il suffit d'un coup de grep -v '^Name' pour retrouver la concision :-)

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

    • [^] # Re: localisation

      Posté par (page perso) . Évalué à  6 .

      Ça serait chouette. Surtout si systemd est utilisé comme session X. Pour gérer les services de sa session avec une interface façon gnome-session-properties.

      Et puis je suppose que systemd pourra rétablir la session, récupérer mes fichiers corrompus, faire le café et faire revenir ma femme. \o/

  • # troll mode

    Posté par (page perso) . Évalué à  -10 .

    TODO

    Implement services.msc utility for linux

  • # Merci

    Posté par . Évalué à  7 .

    Merci pour cette dépêche instructive.

    Je deviens probablement un vieux con, mais j'avoue que je préfère un bon script sh appelant awk, grep et sed.

    C'est certainement une question d'habitude, mais ça donne l'impression de maîtriser ce qui ce passe au boot (c'est un peu ce qui m'a plus chez GNU/Linux).

    C'était mieux avant, mais, ça démarrait moins vite certes ...

    • [^] # Re: Merci

      Posté par . Évalué à  1 .

      Arff
      s#ce passe#se passe#

    • [^] # Re: Merci

      Posté par . Évalué à  6 .

      Il y a a mon avis des besoins différents suivant l'utilisation desktop ou serveur de la machine.
      Pour un desktop, on peut effectivement demander au système de booter vite - encore qu'on peut toujours mettre le machine en veille et avoir un réveil quasi-instantané.
      Quant aux serveurs, honnêtement le temps de boot, on s'en moque un peu... Est-ce que dans ce cas c'est vraiment rentable de passer à systemd ? ( gain fonctionnel vs risque-de-casser-ce-qui-marche )

      • [^] # Re: Merci

        Posté par . Évalué à  3 .

        Personnellement je ne redémarre ma machine de bureau quasiment jamais.
        J'ai tenté 2~3 fois de modifier/créer des fichiers de lancement upstart (ubuntu) et j'en garde un souvenir pénible.

        Peut être que la killer feature de systemd concerne les processus orphelins, à voir ...

      • [^] # Re: Merci

        Posté par . Évalué à  10 .

        Je suis d'accord avec toi sur le fait que systemd ne soit pas une necessite absolue.

        Neanmoins il a plusieurs atouts pour les deploiements professionels, notemment sa plus grande robustesse, son plus grand controle des processus enfants, les snapshots et j'en passe et des meilleures.

        La vitesse de boot c'est un peu de la poudre aux yeux, les distribs' qui utilisent upstart ou sysvinit bootent deja bien vite (moins de 30s d'habitude). Je pense que c'est juste pour montrer qu'on gagne sur tous les tableaux avec systemd.

        Il y a un dernier point qui peut etre une avantage ou non, systemd impose une normalisation des distros et des services. Finis les seds, finis les petits hacks a droite a gauche dans les fichiers init, finis les distros farfelues qui collaient les fichiers de config la ou elles le voulaient. Certains diront que c'est une bonne chose de normaliser ainsi, d'autres penseront que c'est un obstacle a la possible innovation du systeme et a leur liberte en tant qu'utilisateur en general.

        • [^] # Re: Merci

          Posté par . Évalué à  10 .

          La vitesse de boot c'est un peu de la poudre aux yeux, les distribs' qui utilisent upstart ou sysvinit bootent deja bien vite (moins de 30s d'habitude). Je pense que c'est juste pour montrer qu'on gagne sur tous les tableaux avec systemd.

          D'autant que, et ce n'est pas mis en avant dans la dépêche, un autre avantage notable au fait de permettre le lancement de certains services "à la demande" (activation par accès fs, ou socket "à la inetd", ou appel dbus), c'est aussi (outre cette histoire de vitesse) de permettre d'alléger la consomation mémoire.

          Je ne sais pas vous, mais ça me fend le coeur d'avoir un cuspd (et modem-manager, et wpa_supplicant, et bluetoothd, ...) installés et lancés par défault par mes distros, sur mon vieux laptop avec lequel j'imprime une fois par an.

          Bravo à systemd pour offrir une solution sans perte de fonctionalité (et en laissant l'option de lancer le service systématiquement, par ex. pour un serveur d'impression d'entreprise).

          • [^] # Re: Merci

            Posté par . Évalué à  3 .

            Le swap est là pour ça. Les services et programmes inutilisés s’y retrouvent invariablement. Ça ne vaut d’ailleurs pas que pour les services « pas encore démarré », mais aussi pour les service « utiles seulement au démarrage ou une fois l’an » aka le gestionnaire de connexion ou ton cups que systemd n’ira pas éteindre après l’impression, par contre il ira en swap.

            • [^] # Re: Merci

              Posté par (page perso) . Évalué à  10 .

              Non, il ira en swap seulement quand le système aura besoin de mémoire. Or passer en swap c'est lent. Donc ça ralentit bien le système.

              "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

              • [^] # Re: Merci

                Posté par . Évalué à  2 .

                À ce propos, je suis étonné qu’il n’existe pas de mise en cache préventive (en tout cas je n’ai rien trouvé de tel). Il me semble pourtant que c’est une idée assez bête. Des infos ?

                • [^] # Re: Merci

                  Posté par . Évalué à  10 .

                  Bon ben voilà, je l’aurais parié que les dév. kernel ont implémenté ça de façon un peu plus intelligente que d’attendre d’avoir besoin de RAM pour mettre en swap, et s’éviter ainsi de l’écriture disque pile au moment où on a aussi besoin de lire.

                  C’est expliqué avec un joli graphe un peu plus bas. Si j’ai bien compris, lorsque la RAM qui peut être allouée descend en dessous d’un certain seuil on écrit des données en swap. Donc bien avant de se retrouver totalement à cours de RAM. Si jamais l’allocation est très importante et que la quantité libre de RAM continue de baisser jusqu’à un second seuil, alors seulement à ce moment, l’allocation est limitée par la vitesse d’écriture du swap. Le but du jeu est que ce dernier cas de figure ne se présente que rarement avec les bons jeux de paramètres. Sur la Debian, ce serait /proc/sys/vm/min_free_kbytes qui permettrait d’agir sur la quantité de RAM libre en-dessous de laquelle le système doit commencer à mettre en swap. Il est fixé à ~45 Mo par défaut (soit plus qu’une Debian avec postfix, apache, cyrus-imap au démarrage).

                  Enfin bref : le swap est là pour libéré la RAM, et le coût de mise en swap est limité vis-à-vis de la demande en mémoire vive (tant qu’elle est raisonnable). De toute façon systemd ne change rien à ce principe : une fois qu’il a lancé le service c’est le swap qui prendra le relais sur une machine qui en a besoin ; systemd va se contenter d’introduire un délai dans ce comportement. Donc je vois pas bien pourquoi se priver du service du swap dans l’intervalle démarrage de la machine — premier accès au service, alors que c’est ce même swap qui entrera en jeu pour toute la durée de vie du service qui est rarement utilisé.

                  • [^] # Re: Merci

                    Posté par . Évalué à  9 .

                    Si j'essaye de résumer les deux solutions

                    1. Solution à la demande

                      • lancer le service à la demande
                    2. Solution pré-chargement

                      • lancer le service au démarrage, au moment où il y a pleins d'I/O
                      • attendre que la pression mémoire pousse a récupérer de la mémoire du service
                      • virer les pages de texte (le binaire) de la mémoire puisqu'il est déjà sur disque
                      • swapper sur disque les pages de données
                      • a la première sollicitation remonter les pages de texte depuis le fichier
                      • remonter les pages de données du swap

                    Au final dans la seconde solution, on a chargé une fois de plus le binaire depuis le disque, on a lu et écrit une fois toutes les données, et on a fait le lancement à un moment ou le disque est très sollicité.

                    Le seul avantage qu'on a, c'est que le service réponds plus rapidement, puisqu'il a déjà été initialisé. Mais en général le temps d'initialisation est ridicule devant le temps de lecture.

      • [^] # Re: Merci

        Posté par . Évalué à  10 .

        Pour le risque de casser ce qui marche, c'est surtout lié à la jeunesse de systemd et des procédés de migrations prévus par les distributions. Personnellement, j'ai testé le passage à systemd sur un portable Debian il y a quelques mois. A l'époque, après migration mon eth0 n'était pas initialisé, il avait fallu corriger ça à la main. Le bug est bien sûr corrigé depuis. En dehors de ceci, tout a fonctionné très bien et l'accélération du démarrage est spectaculaire : grosso modo, je suis passé de 30 s. à 5. (*)

        Sinon l'article précise bien que le temps de démarrage n'est pas le seul atout de systemd. L'outil est surtout prévu pour améliorer la gestion des services, ce qui est particulièrement utile pour les serveurs. Par exemple, la mise à jour d'un démon, et donc son redémarrage, sans interruption du service. Ou encore le suivi des processus orphelins grâce aux cgroups.

        (*) Ce portable pas récent a une carte Nvidia. Plus de driver nv pour Xorg, donc le choix doit se faire entre Nouveau et le driver proprio. Le premier fait planter l'hibernation (plus précisément, la reprise). Le second refuse de dialoguer avec un vidéoprojecteur. Résultat, j'utilise Nouveau mais le temps de démarrage est crucial, faute d'hibernation.

      • [^] # Re: Merci

        Posté par . Évalué à  9 .

        Perso je vois quelques avantages sur un serveur. À mon lieu de travail, sur certaines machines avec de fortes contraintes d'uptime à respecter sur des services donnés, bien souvent on se retrouve, sur des trucs un foireux, à devoir mettre en place des scripts de redémarrage de certains services (souvent des trucs à base de tomcat d'ailleurs...) lorsqu'ils plantent ou cessent de répondre.

        La surveillance des services et la capacité de garder les requêtes qui arrivent quand le service est down pour les lui transmettre une fois démarré semblent intéressantes.

        Le fait de killer proprement les services avec des cgroup devrait également éviter les problèmes liés aux scripts d'init qui n'éteignent pas tout ce qu'ils ont démarré quand on les stoppe. J'imagine aussi qu'on doit pouvoir se passer de xinetd et d'autofs au moins pour une partie des cas d'usages. Et le fait d'avoir directement le support de fonctionnalités qu'il fallait coder à la main dans chaque script d'init devrait aider à réduire leur complexité et le nombre de bugs dans ceux-ci.

        Bref, ça devrait être plus simple, plus fiable et moins bancal dans pas mal de cas que les scripts d'init traditionnels et les hacks foireux parfois mis en place pour les accompagner, et ça ne peut qu'être bénéfique, qu'on soit sur un serveur ou un desktop.

    • [^] # Re: Merci

      Posté par . Évalué à  4 .

      Pareil.

      Va débugger un serveur SSH qui ne démarre qu'en cas de connexion entrante.

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: Merci

        Posté par . Évalué à  4 .

        telnet ?

        ok ->[]

      • [^] # Re: Merci

        Posté par . Évalué à  1 .

        Rien ne t'empêche de le lancer toi même.

      • [^] # Re: Merci

        Posté par . Évalué à  -7 .

        Et va sécuriser une machine (de bureau, install de base) qui lance SSH automatiquement à la première tentative de connection d'un attaquant. Personnellement je ne lance le démon ssh sur ma machine de bureau que quand je vais en avoir besoin.

        • [^] # Re: Merci

          Posté par . Évalué à  2 .

          Tu pourras certainement désactiver le lancement de SSH comme tu le fais actuellement.

          • [^] # Re: Merci

            Posté par . Évalué à  -9 .

            Moi je pourrai le faire, mais si l'install par défaut d'une distrib active cette fonctionnalité (alors que la majeure partie des utilisateurs débutants n'ont aucun besoin de ssh), alors cela représente un risque d'intrusion pour des centaines de milles ou des millions de gens (une distrib sud-africaine indique avoir plus d'un million de comptes enregistrés dans son cloud).

            • [^] # Re: Merci

              Posté par . Évalué à  4 .

              Un paquet openssh-server n'est pas forcement installe par defaut si ?

            • [^] # Re: Merci

              Posté par . Évalué à  10 .

              En fait systemd c'est de la merde par ce qu'on peut le configurer pour démarrer un démon par défaut (au choix de la distrib) quand le paquet est installé; contrairement à tout autre système d'init...

              Et y'a un moins une personne qui t'a pertinenter pour des âneries pareils ?

              Si tu veux pas démarrer sshd tu peux.
              Si tu veux démarrer sshd comme avant en dur tu peux.
              Si tu veux démarrer sshd en lazy tu peux.
              Si tu veux ton truc perso avec ton script maison tu peux.

              • [^] # Re: Merci

                Posté par . Évalué à  -6 .

                1) Je n'ai pas critiqué systemd en soi.

                2) Je n'ai pas dit de quoi que ce soit que était « de la merde ».

                3) J'apprécierais que tu évites de critiquer mes propos en les qualifiant d'« âneries pareils ». En effet je suis très sensible aux fautes d'orthographes je m'attendais à ce que tu les qualifies plutôt d'« âneries pareilles ». Je te suggèrerais en outre de placer l'adjectif en position antéposée, « de pareilles âneries », comme dans l'exemple rapporté par le dictionnaire d'Émile Littré*. Ou, au choix, de ne pas insulter les gens du tout.

                J'ai critiqué précisément un exemple cité de configuration de ce système, qui est de mettre un démarrage automatique sur une action ayant une implication forte sur la sécurité, ssh étant utilisé dans un contexte qui ne profite que de façon très limitée d'un tel automatisme, qui en revanche peut créer un trou de sécurité.

                Après, je me doute bien que les gens éduqués savent désactiver les fonctions qui ne leur sont pas utiles.

                • [^] # Re: Merci

                  Posté par (page perso) . Évalué à  10 .

                  En clair, tu nous dis que t'a rien compris:

                  • sysV: ssh installé et lancé

                  • systemd: en attente d'écoute sur port 22 pour lancer ssh

                  je vois pas la différence niveau sécu pour le newbie, si la distrib active ssh par défaut ou l'écoute ssh dans systemd par défaut, c'est la meme chose...

                • [^] # Re: Merci

                  Posté par . Évalué à  0 .

                  s/suggèrerais/suggérerais/

                  (À pinailleur, pinailleur et demi :-)

                  Sinon, d'accord avec toi sur le fond...

                  • [^] # Re: Merci

                    Posté par . Évalué à  4 .

                    C'est la forme recommandée depuis les révisions de 1976 et 1990, voir le Wiktionnaire :wikt:suggèrerais. (Par ailleurs l'orthographe révisée de 1990 est enseignée dans l'Éducation nationale depuis la rentrée 2009, voir Rectifications orthographiques du français en 1990.) Mais tant qu'on est à pinailler, c'est la coquille suivante qu'il fallait trouver : s/orthographes/orthographe/

                    • [^] # Re: Merci

                      Posté par . Évalué à  2 .

                      s/enseignée/recommandée/

                      On n'enseigne plus l'orthographe dans l'éducation nationale.

            • [^] # Re: Merci

              Posté par . Évalué à  2 .

              (une distrib sud-africaine indique avoir plus d'un million de comptes enregistrés dans son cloud).

              L’île de Man c'est pas en Afrique du sud ;)

              Please do not feed the trolls

          • [^] # Re: Merci

            Posté par . Évalué à  4 .

            /etc/init.d/ssh

            Usage: /etc/init.d/ssh {start|stop|reload|force-reload|restart|try-restart|status|stop-autostart-at-connect|start-disable-autostart|force-reload-if-not-on-autostart|autostart-satus|manually-start-if-on-autostart}.

            Ça va être rudement simple tout ça je sens.

            THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

            • [^] # Re: Merci

              Posté par (page perso) . Évalué à  2 .

              y-a-t'il vraiment un intérêt à avoir tant d'options...
              {start|stop|restart} doivent suffire dans 99.9% des cas, non ?

              • [^] # Re: Merci

                Posté par (page perso) . Évalué à  8 .

                reload est tres utile pour ne pas avoir d'interruption de service

                • [^] # Re: Merci

                  Posté par (page perso) . Évalué à  4 .

                  Ou status, pour savoir si le service est lancé. Ce dernier manque à pas mal de distributions, ou celles qui l'ont font un exit 0 dans tous les cas rendant l'utilisation dans un script difficile.

                  DLFP >> PCInpact > Numerama >> LinuxFr.org

      • [^] # Re: Merci

        Posté par . Évalué à  10 .

        Une "killer feature server" de systemd, c'est qu'il sait capturer les messages du kernel (early boot) et les infos de démarrage des services, et sait envoyer tout ça dans syslog (ou sur le port série si besoin).

        Avec l'init SysV, les messages affichés lors du boot ne sont visible que sur la console, pas dans les logs.

        C'est une aide bien pratique justement pour débuguer les problèmes au démarrage.

    • [^] # Re: Merci

      Posté par . Évalué à  10 .

      Nostalgie: Synonymes [...]amertume[...]
      Sache que systemd ne vous empêche pas d'utiliser des scripts abscons et inmaintenable puisque "Le système est compatible avec les anciens scripts SysVinit. Les informations LSB et chkconfig (de Red Hat) ainsi que celles de Debian et d'OpenSUSE sont utilisées lorsqu'elles sont disponibles". Testez le bouzin avant de couin^W^W d'émettre un avis (avec tout le restecp que je vous dois).

    • [^] # Re: Merci

      Posté par . Évalué à  8 .

      Il est vrai que la seule distrib que j'ai eu un vrai plaisir à voir booter, c'était il y a déjà quelques années: une Slackware configurée aux petits oignons. Ne démarraient que les choses utiles, et dans le bon ordre.
      C'est clair, c'était mieux à vent.

      • [^] # Re: Merci

        Posté par (page perso) . Évalué à  4 .

        Tu l'as écrit... "configurée aux petits oignons", et ça, ça prend, ça demande de l'expérience, et il faut l'adapter à chaque cas.

      • [^] # Re: Merci

        Posté par . Évalué à  2 .

        Il me semble justement que la Slackware n'utilisait pas System V, mais une init de type BSD. Et ça roXXorait des mamans ourses.

  • # systemd / Debian

    Posté par (page perso) . Évalué à  6 .

    Debian a un paquet dans « unstable » et devrait permettre de choisir un système ou l’autre dans une prochaine version.

    Je n'ai lu qu'une partie de cet interminable thread mais je suis moins optimiste quant à l'arrivée prochaine de systemd dans Debian.

    http://lists.debian.org/debian-devel/2011/07/threads.html#00269

    As tu une source à citer pour appuyer l'affirmation ci-dessus ?

    En tout cas, merci pour cet article :)
    k

    • [^] # Re: systemd / Debian

      Posté par . Évalué à  3 .

      Y'aura un dépôt tiers, comme c'est la mode pour Ubuntu. Faudra jouer du apt-key avec le certificat auto-signé d'un dépôt hébergé en Russie par Google (non, non, pas d'erreur).

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: systemd / Debian

        Posté par (page perso) . Évalué à  2 .

        Trop gros ton troll, ça passera pas.
        Pour information, systemd est déjà dans Debian (la unstable pour le moment). Il se retrouvera donc forcément dans la stable à un moment ou à un autre. Après la question de quand il sera mis par défaut reste en suspens.

    • [^] # Re: systemd / Debian

      Posté par . Évalué à  4 .

      Je n'ai pas vraiment plus d'informations que ce qui a été cité dans l'article et dans le thread que tu pointes. C'est une déduction de:

      • systemd est déjà dans testing.
      • un certain nombre de paquets dans testing sont déjà compatibles systemd

      Il y a actuellement un problème qui touche également upstart: sysvinit est taggé comme "Essential".

      Enfin je n'ai pas parlé d'avoir systemd comme système par défaut; pour la principale raison qu'il n'est pas compatible avec Debian GNU/Hurd ni avec Debian GNU/*BSD

      • [^] # Re: systemd / Debian

        Posté par (page perso) . Évalué à  2 .

        Enfin je n'ai pas parlé d'avoir systemd comme système par défaut

        Oui, oui, je réagi uniquement à l'affirmation qu'il serait proposé par Debian comme alternative à sysV. Cela demande beaucoup de travail pour que systemd soit officiellement proposé (par exemple lors d'une installation).

    • [^] # Re: systemd / Debian

      Posté par (page perso) . Évalué à  2 .

      • [^] # Re: systemd / Debian

        Posté par (page perso) . Évalué à  8 .

        Oui systemd est dans Debian, cependant on est, àmha, encore loin du jour ou le projet Debian proposera officiellement le choix entre plusieurs systèmes de démarrage. Il faudrait pour cela que tous les paquets fournissent des scripts (ou une conf) de démarrage pour les différents systèmes proposés (une rapide recherche m'indique qu'il y a environ 300 paquets avec un script init). De plus il faut gérer le cas linux à part car Debian propose kFreeBSD et GNU/Hurd comme noyau alternatif.

        En bref, la présence d'un paquet logiciel dans testing n'est pas une garantie d'une quelconque intégration de ce logiciel dans la distribution.

        On est cependant tous d'accord qu'il y a là un défit pour Debian qui est à part dans le monde des distributions du fait des noyaux non-linux qu'elle propose.

    • [^] # Un résumé du débat systemd / Debian est disponible sur LWN

      Posté par . Évalué à  10 .

      Comme d'habitude LWN fournit un résumé de grand qualité: http://lwn.net/Articles/452865

      Cependant, le point qui m'a le plus intéressé (plutôt que le débat classique portable vs non-portabilité) est l'avis d'Al Viro: http://lwn.net/Articles/453529/
      Il déteste systemd car il dépend de partie du kernel qu'il n'aime pas comme les cgroup et fanotify, intéressant car j'ignorais que ces parties du kernel était si mal vue..

      Il n'aime pas D-Bus, il préfère plumber(*) , ce n'est pas la première critique que je vois de D-Bus, intéressant aussi: quelqu'un connait-il les deux pour donner son avis?

      *un protocole dévoloppé pour Plan9: http://en.wikipedia.org/wiki/Plumber_(program)

      • [^] # Re: Un résumé du débat systemd / Debian est disponible sur LWN

        Posté par . Évalué à  10 .

        Moi, j'aurais bien aimé qu'il dise pourquoi cgroups et fanotify sont mal fichus au lieu de l'annoncer comme une évidence. Quelqu'un connaît ces points faibles ?

      • [^] # Re: Un résumé du débat systemd / Debian est disponible sur LWN

        Posté par (page perso) . Évalué à  3 .

        A propos, une des objections de Juliusz Chroboczek qui a lancé le débat chez Debian, porte sur l'utilisation des sockets pour activer un démon. Il est très bref dans son post initial, mais quelques jours plus tôt, sur la liste de discussion de Polipo, il a expliqué s'est laché sur le sujet:
        en gros l'utilisation de socket complexifie le code ce qui fragilisent l'init, et en plus si les démons d'activation de socket se vautrent, adieu les services (alors que ce n'est pas le cas avec inetd).
        Bon il est deux heures et demi du matin , j'espère que je ne raconte pas trop de conneries... corrigez-moi.

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # Diverses remarques

    Posté par . Évalué à  10 .

    Pour la racine (« / »), cela ne présente pas d’intérêt ; mais pour les grosses volumétries qui peuvent être montées sur « /home », ou pour des partitions de données qui ne sont pas nécessaires au démarrage du système, cela présente un gain important.

    Comment ça se traduit concrètement ?

    Supposons que le /home (souvent la plus grosse partition pour un particulier) soit en train de faire un fsck. Ça n'empêche pas de continuer à booter et de proposer à l'utilisateur de s’authentifier (/etc/shadow et /ect/password sont dispo).

    Qu'est ce qui se passe si le fsck est encore en cours et que l'utilisateur tente d'ouvrir une session ?

    Est ce que ça reste gelé le temps que le fsck se finisse ?

    Si c'est le cas, le remède est pire que le mal. Au bout d'une minute ou deux, l'utilisateur appuie sur reset.

    D’après Lennart cette approche est condamnée à être lente. Sur son système, les scripts dans « /etc/init.d/ » appellent grep au moins 77 fois, awk l’est 92 fois, cut, 23 fois, et sed, 74 fois. À chaque appel, un processus doit être démarré, les bibliothèques résolues, la localisation initialisée, etc.. Après une manipulation de quelques octets, les données doivent être retournées à l’appelant via un descripteur de fichier et le processus est détruit. En outre, les scripts sont très sensibles à l’environnement et peu adaptés à la gestion des erreurs et des exceptions.

    Dis donc Lennart, tu ne serais pas en train de militer pour une réécriture de tous ces scripts en scripts Perls auto-suffisants ? Hein ? Avoue :)

    Le grand absent est Ubuntu, qui a beaucoup investi dans Upstart et n’a pas manifesté, pour l’instant, de volonté de passer à systemd (bien qu’un début d’intégration existe).

    De toutes façons une fois intégré à Debian, l'effort à fournir pour l'intégrer à Ubuntu est minimal.

    • [^] # Re: Diverses remarques

      Posté par . Évalué à  4 .

      Le problème du fsck sera la même avec ou sans systemd. Si l'utilisateur est capable de reset en plein fsck sans systemd, il est fort propable qu'il le fasse avec un autre init.
      Je crois qu'une intervention avait eu lieu au fosdem à ce propos (une histoire de partage samba). Poettering avait éludé en expliquant qu'un fsck sur un fs récent, c'etait pas si long et qu'on réglerait ce problème spécifique avec une règle de dépendance (mais il a admis que c'est un problème).

      • [^] # Re: Diverses remarques

        Posté par (page perso) . Évalué à  6 .

        Le problème du fsck sera la même avec ou sans systemd. Si l'utilisateur est capable de reset en plein fsck sans systemd, il est fort propable qu'il le fasse avec un autre init.

        Oui, mais ce n'était pas la question.

        La question, c'est comment est géré ce cas.

        Dans un système d'init classique, le system écrit qu'il fait son fsck et rien d'autre ne se passe tant qu'il n'a pas finit.

        Or si avec systemd le boot se poursuit, l'utilisateur sera-t-il informé de la même manière que le système est en train de faire un fsck ou pas ?

        Poettering avait éludé en expliquant qu'un fsck sur un fs récent, c'etait pas si long

        Quelques Téra de DD, ça prend quand même un peu de temps (tout le monde n'a pas un SSD de 80Go).

        et qu'on réglerait ce problème spécifique avec une règle de dépendance

        Ah ok.

      • [^] # Re: Diverses remarques

        Posté par . Évalué à  6 .

        Avec un init classique l'utilisateur est bloqué devant la barre de progression du fsck, donc il attend que ça se termine.

        Avec systemd le fsck se fait au moment où la partition est montée, c'est à dire au moment où l'utilisateur se log. Et à ce moment là à priori il ne vois pas la barre de progression, il ne sais pas qu'il y a un fsck en cours, il a seulement l'impression que login a freezé.

      • [^] # Re: Diverses remarques

        Posté par . Évalué à  9 .

        Si l'utilisateur est capable de reset en plein fsck sans systemd, il est fort propable qu'il le fasse avec un autre init.

        Encore faut-il savoir qu'un fsck est en cours quand le système a l'air bloqué.

    • [^] # Re: Diverses remarques

      Posté par . Évalué à  4 .

      fsck n'a pas d'avenir.
      une granularité "atomique" des snapshots sera plus rapide ET plus efficace.

      • [^] # Re: Diverses remarques

        Posté par (page perso) . Évalué à  9 .

        D'accord, mais en attendant que tout le monde passe à un fs moderne, on fait quoi ?

        On dit aux utilisateurs des autres fs d'aller se faire foutre ?

        Ou juste de ne pas utiliser systemd ?

        • [^] # Re: Diverses remarques

          Posté par . Évalué à  4 .

          en attendant

          On continue avec l'existant qui fonctionne (très) bien ?

          • [^] # Re: Diverses remarques

            Posté par . Évalué à  3 .

            On continue avec l'existant qui fonctionne (très) bien ?

            C'est bien de le rappeller, car avec toutes ces innovations, annonces sensationnelles, on a l'impression que "Linux" c'est de la merde.

            Pour le FS, je n'ai jamais eu de corruptions en 8 ans de reiserfs 3.4 & 3.6 sur des volumes toujours grandissants.

            Le point positif et principal que je trouverais à SystemD, c'est la normalisation entre les distros.

        • [^] # Re: Diverses remarques

          Posté par . Évalué à  10 .

          On leur dit fsck !

      • [^] # Re: Diverses remarques

        Posté par . Évalué à  1 .

        Je ne vois pas le rapport entre une fonctionnalité de vérification du système de fichiers et une fonctionnalité de production d'instantanés.
        (les instantanés eux-mêmes devraient être vérifiés par fsck, d'ailleurs)

        • [^] # Re: Diverses remarques

          Posté par . Évalué à  1 .

          La phrase est trop résumé, oui. Mais comme dirait l'autre "on ne parle bien que de ce que l'on maîtrise" (bon c'est joli, c'est pour illustrer ici, mais j'en connais plein qui parlent mal de ce qu'il maîtrise (des devs.) et encore plus qui parlent bien de ce qu'ils ne comprennent pas (qui dit 'commericaux'?))

          ça te gonfles pas le lost+found toi ? Avec au mieux un gros bordel dedans, au pire un truc tout pété ?

          Fsck ultra-rapide->incohérent_à_un_endroit->renvoi_snapshot_de_cet_endroit, ça serait mieux, non ? et je pari dessus.

          • [^] # Re: Diverses remarques

            Posté par . Évalué à  2 .

            ça te gonfles pas le lost+found toi ? Avec au mieux un gros bordel dedans, au pire un truc tout pété ?

            Ça fait des années que je n'ai pas vu un système de fichiers cassé, donc c'est difficile de répondre.

            Fsck ultra-rapide->incohérent_à_un_endroit->renvoi_snapshot_de_cet_endroit, ça serait mieux, non ? et je pari dessus.

            Je n'ai pas compris. S'il y a un problème au fsck, tu remplaces silencieusement par un vieux snapshot?
            Et si le snapshot lui-même fait partie des données corrompues ?

            • [^] # Re: Diverses remarques

              Posté par . Évalué à  -5 .

              Ça fait des années que je n'ai pas vu un système de fichiers cassé

              ha non, rien :p

              S'il y a un problème au fsck, tu remplaces silencieusement par un vieux snapshot?
              Et si le snapshot lui-même fait partie des données corrompues ?

              ha ben rien non plus :)

    • [^] # Re: Diverses remarques

      Posté par . Évalué à  2 .

      Qu'est ce qui se passe si le fsck est encore en cours et que l'utilisateur tente d'ouvrir une
      session ?
      Est ce que ça reste gelé le temps que le fsck se finisse ?

      Il y a de grosse chance que oui :)
      Apres des hacks seront surement ajouté pour bloquer le dm tant que le home de l'utilisateur n'est pas monter..

      • [^] # Re: Diverses remarques

        Posté par . Évalué à  2 .

        Je suis pas sur qu'il y ait besoin de gros hack. J'ai mon /home en dmcrypt, et systemD attend tout seul comme un grand que je déverrouille la partition pour terminer.

        • [^] # Re: Diverses remarques

          Posté par (page perso) . Évalué à  1 .

          Sans doute que gdm bloque lui même ... parce qu'il à besoin de lire des fichiers dans les homedirs il me semble.

        • [^] # Re: Diverses remarques

          Posté par (page perso) . Évalué à  2 .

          Non ça bloquera selon le login saisi car le home des différents utilisateurs peuvent être sur différentes partitions et donc nécessiter un fsck ou pas.

      • [^] # Re: Diverses remarques

        Posté par . Évalué à  0 .

        ya une solution très simple : lancer fsck lors de l’arrêt, pas lors démarrage.

        Please do not feed the trolls

        • [^] # Re: Diverses remarques

          Posté par (page perso) . Évalué à  9 .

          Oh bah oui, c'est pas con ça ! L'extinction se passe mal, au prochain reboot, pas de fsck, tu bosses avec un système de fichier potentiellement incohérent et il ne checke qu'à la prochaine extinction. Du grand art.

          • [^] # Re: Diverses remarques

            Posté par (page perso) . Évalué à  4 .

            C'est ce que je voulais répondre au début mais je pense que c'était à propos du fsck de maintenance (tous les X jours ou X montages)… pas sûr que ce soit encore activé sur les distributions grand public, l'utilité a pas mal diminué. Quoique, avec ext4 le fait de faire un fsck permet de rendre le prochain fsck plus rapide.

            DLFP >> PCInpact > Numerama >> LinuxFr.org

            • [^] # Re: Diverses remarques

              Posté par (page perso) . Évalué à  3 .

              Ubuntu (et Linux Mint) font une vérification des disques, de la même façon qu'Archlinux le faisait l'année dernière (je ne pense pas que ça ait changé entre temps, même si j'en sais rien). Je suppose que c'est un fsck qui est réalisé.

              Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

          • [^] # Re: Diverses remarques

            Posté par . Évalué à  4 .

            Ça ne change rien. Il n'est pas question de démarrer avec un FS corrompus en connaissance de cause. J'ignore quel est le mécanisme qui détecte un arrêt brutal et enclenche le fsck, mais il n'est pas question de le virer.

            Le fait est que les utilisateurs s'impatientent moins quand ils arrêtent leur ordinateur que quand ils le démarrent. Alors pour le fsck de routine (celui qui est automatique tout les x montages) c'est parfaitement acceptable.

            Please do not feed the trolls

            • [^] # Re: Diverses remarques

              Posté par . Évalué à  6 .

              Alors là je ne suis absolument pas d'accord.
              Lorsque j’éteins mon portable pour aller prendre le train, j'ai absolument pas envie qu'il mette 5 minutes à faire ses connerie.

              Quand j'allume le PC en général je vais faire un tour à la machine à café ou aux fausses d'aisances :D Ce qui fait que j'en ai rien à battre qu'il mette 5 minutes de plus à booter.

              Il ne faut pas décorner les boeufs avant d'avoir semé le vent

              • [^] # Re: Diverses remarques

                Posté par . Évalué à  0 .

                Ton ordinateur a besoin que tu le surveille pour s'arrêter ?
                Le mien est autonome, souvent il fini même de s'arrêter dans le sac.

                Please do not feed the trolls

        • [^] # Re: Diverses remarques

          Posté par . Évalué à  4 .

          Il y a une solution très simple : ne pas lancer fsck.

          Ben oui, ReiserFS fonctionne bien :)

        • [^] # Re: Diverses remarques

          Posté par (page perso) . Évalué à  4 .

          C'est un problème pour tous les systèmes sur batteries (portable, onduleurs…)

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # Re: Diverses remarques

      Posté par . Évalué à  5 .

      Est ce que ça reste gelé le temps que le fsck se finisse ?

      Non, ça affiche un truc Gnome3 avec des widgets codés par Google en Adobe AIR et du web 3.0 sémantique plein le bureau pour te dire, dans une boîte de dialogue au style pompé sur Mac OS X Lion (sauf qu'elle fait planter tout le serveur X si tu essaies de la fermer parce qu'elle est buggée et tourne avec les droits root),

      Ayé, on a bien bloaté vot' Linux pire qu'un Vista grand cru de la belle époque où Microsoft se faisait caca dessus. Rassurez-vous: cette merde n'est pas portée sur BSD. Et les barbus possédés par Beastie vous attendent.

      startx, c'était mieux.

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: Diverses remarques

      Posté par . Évalué à  0 .

      Qu'est ce qui se passe si le fsck est encore en cours et que l'utilisateur tente d'ouvrir une session ?

      Est ce que ça reste gelé le temps que le fsck se finisse ?

      Certainement.

      À mon avis, c’est juste une mauvaise idée de monter /home en automatique (à moins qu’il ne soit sur un serveur distant).
      Mais systemd n’empêche pas d’utiliser fstab comme avant pour qu’il soit monté en dur avant le gestionnaire de connexion.

      Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

      • [^] # Re: Diverses remarques

        Posté par . Évalué à  2 .

        Mais systemd n’empêche pas d’utiliser fstab comme avant pour qu’il soit monté en dur avant le gestionnaire de connexion.

        C'est même le par défaut. Pour faire du autofs il faut le spécifier explicitement via un 'comment=systemd.automount' à mettre dans les options de montage de /etc/fstab.

  • # utilisation des cgroups ?

    Posté par . Évalué à  1 .

    Je suis curieux de savoir si cette utilisation des cgroups par user ne va pas poser de problemes avec les patchs qui prévoyaient de nouveaux cgroups à chaque terminaux etc. De mémoire, il est impossible de creer un cgroup à l'interieur d'un autre.

    • [^] # Re: utilisation des cgroups ?

      Posté par . Évalué à  5 .

      Les cgroups sont arborescents donc ça ne pose pas de problème : on peut créer des "sous"-cgroups dans un cgroup.

      • [^] # Re: utilisation des cgroups ?

        Posté par . Évalué à  2 .

        Merci. Si tu as un lien je suis preneur. Je n'ai rien trouvé.

        • [^] # Re: utilisation des cgroups ?

          Posté par . Évalué à  3 .

          Le mieux est probablement de lire les premiers chapitres de la documentation du kernel: http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt

          A hierarchy is a set of cgroups arranged in a tree, such that every task in the system is in exactly one of the cgroups in the hierarchy, and a set of subsystems; each subsystem has system-specific state attached to each cgroup in the hierarchy. Each hierarchy has an instance of the cgroup virtual filesystem associated with it.

          At any one time there may be multiple active hierarchies of task cgroups. Each hierarchy is a partition of all tasks in the system.

          En résumé: On peut avoir plusieurs hiérarchies; dans chaque hiérarchie on peut mettre plusieurs cgroups. Les processus sont présent une et une seule fois dans chaque hiérarchie.

          Cela permet, par exemple, de définir une hiérarchie pour isoler les services et les sessions; et de définir une seconde hiérarchie n'ayant rien à voir pour les I/O disque.

  • # marche poas chez moi archlinux

    Posté par . Évalué à  -8 .

    salut

    je viens d'essayer sur Arch,
    ca ne fonctionne pas : bloqué apres fsck ....

    dans 1 an ....

    • [^] # Chez moi, si.

      Posté par . Évalué à  2 .

      Ça marche très bien pour moi (et pour au moins une autre personne d’après son commentaire à l’interview de Lennart Poettering).

      As-tu suivi les indications qui sont ici ?

      Sinon, bloqué « après fsck », sur un système de démarrage asynchrone, ça ne nous dis pas grand chose...

      Soit tu as une unité qui bloque, mais il faut savoir laquelle (systemd émet un message au démarrage de chaque unité), soit tu n’as pas configuré les cibles correctement et systemd ne sait pas quoi faire après fsck.

      Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

      • [^] # Re: Chez moi, si.

        Posté par . Évalué à  1 .

        J'ai également testé sous Archlinux mai X ne se lance pas. Vu que je ne démarre pas souvent mon ordi je ne me suis pas trop pris la tête.

        • [^] # Re: Chez moi, si.

          Posté par . Évalué à  2 .

          Il faut indiquer à systemd qu’il doit lancer ton gestionnaire de connexion au démarrage.

          Par exemple : systemctl enable gdm.service

          Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

          • [^] # Re: Chez moi, si.

            Posté par . Évalué à  3 .

            Salut,

            Cela doit être ça il ne sait pas quoi faire....

            comment on fait pour lui dire , s'il te plaît, loggue toi automatiquement avec l'utilisateur "val" et execute /home/val/.xinitrc

            Avec les scripts classique je sais faire.
            Mais la .....

            PS : oui, oui, pas la peine de taper google "systemd autologin xinitrc", il n'y a rien ...
            PS2 : ni "systemd xinitrc"
            PS3 : ni dans les man, ni les tip FAQ et autres ....

            Si c'est pour installer gdm/kdm/slim ou autre ..... a la place d'un simple script,
            c'est loooouuuuurrrrdddddd

            Si non ça a l'air pas mal, la preuve j'étais parti pour l'utiliser ....

            • [^] # Re: Chez moi, si.

              Posté par . Évalué à  1 .

              Pour Poettering, si tu trouve que consolekit, gdm et leurs dépendances sont trop lourdes pour être inclus dans gnome, tu déteste les handicapés.
              Voir les interventions intempestives sur "Desktop on the Linux... (and BSD, of course)" @ 27c3 http://events.ccc.de/congress/2010/Fahrplan/events/4017.en.html (disponible sur youtube).
              Mais là n'est pas le problème. Ton script SysVinit est censé démarrer. As-tu essayé?
              Pour faire plus propre, fait toi un script systemd. Sinon pour les gorets...Chez moi le contenu de /lib/systemd/system/graphical.target.wants/display-manager.service :
              ExecStart=/etc/X11/prefdm -nodaemon
              Dans ce script:
              if [ -f /etc/sysconfig/desktop ]; then
              . /etc/sysconfig/desktop
              if [ "$DISPLAYMANAGER" = GNOME ]; then
              preferred=/usr/sbin/gdm

              Essaye avec:
              /bin/su - -- val -l -c '/usr/bin/startx /dev/null 2>&1'
              J'ai pas testé parce que moi j'aime bien les handicapés.

          • [^] # Re: Chez moi, si.

            Posté par . Évalué à  2 .

            Finalement j'ai réussi à faire en sorte que ça tombe en marche ! Sauf que le temps de démarrage est identique enfin entre la fin de grub et le début du chargement de fichiers de KDE. Je suppose que par la suite systemd n'apporte pas grand chose.

            systemctl me liste 85 « services » je ne sais pas si c'est beaucoup ou pas.

            • [^] # Combien ?

              Posté par . Évalué à  2 .

              systemctl me liste 85 « services » je ne sais pas si c'est beaucoup ou pas.

              systemctl liste plus ou moins de trucs suivant les options, alors pour qu’on puisse comparer, il faudrait que tu précises ce que tu appelles « service » ou plus simplement que tu indiques la commande exacte que tu as lancée.

              « systemctl list-units » liste toutes les « unités » actives et m’en trouve 106.

              « systemctl --type=service list-units » ne liste que les « services » actifs et m’en trouve 33.

              C’est sous Arch Linux sur mon portable perso, donc pas d’authentification centralisée ni de répertoire distant, pas de serveur mail local non plus, mais X.org avec un gestionnaire de connexion et un ou deux trucs moins courants comme un système de fichiers chiffré et privoxy.

              Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

              • [^] # Re: Combien ?

                Posté par . Évalué à  2 .

                Je suis dans le même cas que toi avec un portable sans trop de services.

                systemctl list-units —> 85 units listed
                systemctl --type=service list-units —> 23 units listed

                • [^] # Re: Combien ?

                  Posté par . Évalué à  1 .

                  C’est que ta configuration doit être vraiment minimale.
                  En fait, j’ai ajouté aussi cups, ip*tables, laptop-mode, systemd-readahead...
                  J’ai aussi désactivé la prise en charge de rc.conf (et donc activé les services au niveau de systemd), ça a peut-être un impact sur le nombre (mais je ne sais pas dans quel sens).

                  Si tu veux, voilà le détail (pour les autres, désolé pour le bruit ; bon, je vais quand même me limiter aux « services »...) :

                  $ systemctl --type=service --full list-units
                  UNIT                      LOAD   ACTIVE SUB     JOB DESCRIPTION
                  acpid.service             loaded active running     ACPI event daemon
                  alsa.service              loaded active exited      Advanced Linux Sound Architecture
                  console-kit-daemon.service loaded active running     Console Manager
                  console-kit-log-system-start.service loaded active exited      Console System Startup Logging
                  cryptsetup@local.service  loaded active exited      Cryptography Setup for local
                  cups.service              loaded active running     CUPS Printing Service
                  dbus.service              loaded active running     D-Bus System Message Bus
                  getty@tty1.service        loaded active running     Getty on tty1
                  ip6tables.service         loaded active exited      IPv6 Packet Filtering Framework
                  iptables.service          loaded active exited      Packet Filtering Framework
                  laptop-mode.service       loaded active exited      Service to extend battery life.
                  lxdm.service              loaded active running     LXDE Display Manager
                  NetworkManager.service    loaded active running     Network Manager
                  ntpd.service              loaded active running     Network Time Service
                  privoxy.service           loaded active running     Proxy service to avoid commercials.
                  rc-local.service          loaded active exited      /etc/rc.local Compatibility
                  remount-rootfs.service    loaded active exited      Remount Root FS
                  rsyslog.service           loaded active running     System Logging Service
                  systemd-ask-password-wall.service loaded active running     Forward Password Requests to Wall
                  systemd-logger.service    loaded active running     Stdio Syslog Bridge
                  systemd-logind.service    loaded active running     Login Service
                  systemd-modules-load.service loaded active exited      Load Kernel Modules
                  systemd-readahead-collect.service loaded active exited      Collect Read-Ahead Data
                  systemd-readahead-replay.service loaded active exited      Replay Read-Ahead Data
                  systemd-remount-api-vfs.service loaded active exited      Remount API VFS
                  systemd-sysctl.service    loaded active exited      Apply Kernel Variables
                  systemd-tmpfiles-setup.service loaded active exited      Recreate Volatile Files and Directories
                  systemd-user-sessions.service loaded active exited      Permit User Sessions
                  systemd-vconsole-setup.service loaded active exited      Setup Virtual Console
                  tor.service               loaded active running     Anonymizing Overlay Network
                  udev-trigger.service      loaded active exited      udev Coldplug all Devices
                  udev.service              loaded active running     udev Kernel Device Manager
                  

                  Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

  • # Passionnant !

    Posté par . Évalué à  10 .

    Vraiment merci ! systemd est vraiment bien expliqué dans cette dépèche.

    J'aimerais lire une dépêche équivalente sur wayland !

    Enfin je lance une bouteille à la mer :)

  • # Lapin compris

    Posté par . Évalué à  1 .

    J'ai du mal à comprendre les réels bonus. Oui, c'est mieux d'avoir moins de PID et une meilleure traçabilité mais est-ce que cela oblige vraiment à faire un système qui ne tourne que sous linux en faisant fi de la compatibilité avec les autres ?

    J'ai l'impression que c'est un jouet et que dans 2 ans on nous dira "ah bien non, en fait on va utiliser le system42 qui est mieux". Il y a de plus en plus de nouveautés poussées dans les distributions sans but réel.

    Au final qu'est-ce que ça apporte ?
    Un démarrage plus rapide -> j'utilise la mise en veille et l'hibernation
    Une manière de mieux écrire les scripts d'inits -> j'en écris pas tous les jours et ils ne changent pas à chaque nouvelle version
    Meilleure intégration avec PAM et SELinux -> je n'utilise pas et j'aimerai savoir si quelqu'un les utilise vraiment. Je veux dire un particulier hein.

    Bref casser un standard pour ça…

    • [^] # Re: Lapin compris

      Posté par . Évalué à  8 .

      Oui.
      Oui, oui et oui d'un point de vue Unix.

      Non d'un point de vue Linux. Combien de temps allons nous devoir encore encore nous passer des avancées du noyau Linux à cause de ça ? Nous passer par défaut, ou bien prendre 50 fois plus de temps admin qu'en gestion systemd pour bénéficier des dernières avancées.

      Les réels bonus ne sont pas ceux que tu cites.

    • [^] # Re: Lapin compris

      Posté par . Évalué à  4 .

      est-ce que cela oblige vraiment à faire un système qui ne tourne que sous linux en faisant fi de la compatibilité avec les autres ?

      Si tu as lu les interviews de Poettering, tu sais qu'il est à fond pour développer pour linux sans s'occuper de la portabilité.

      • [^] # Re: Lapin compris

        Posté par . Évalué à  7 . Dernière modification : le 02/08/11 à 23:43

        J'ai lu l'entretien sur linuxfr et avec lui c'est "marche ou crève" mais est-ce une bonne chose ? Comme le dit Patrick Volkerding (mainteneur de Slackware) :

        My primary concern is that the systemd cabal is going to be pushing it as a dependency wherever possible, but we'll deal with that if it happens. But if any major distributions do actually release using systemd, the world will be stuck with it forever. If that's the case, I hope it turns out to be a good idea...

        Traduction rapide : "Ma principale préoccupation est que la cabale systemd est en train de le pousser comme une dépendance dès que possible, mais nous ferons avec, s'il le faut. Par contre, si toutes les distributions majeures l'utilisent, le monde sera coincé avec pour toujours. Si ça arrive, j'espère c'est une bonne idée…"

      • [^] # Re: Lapin compris

        Posté par . Évalué à  2 .

        C'est une bonne chose: si la tendance actuelle de Linux c'est d'aller dans le mur, il restera les autres unices libres pour recueillir les linuxiens naufragés.

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: Lapin compris

        Posté par . Évalué à  3 .

        tu sais qu'il est à fond pour développer pour linux sans s'occuper de la portabilité.

        Et seulement les versions récentes de linux (celles qui supportent les cgroups).

        On ne probablement pas avoir un système pleinement fonctionel avec un systemd démarrant sur linux 2.6.18 (celui de RHEL 5, Debian Etch, Xen stable etc). J'ai pas testé cela dit ;).

    • [^] # Re: Lapin compris

      Posté par . Évalué à  2 .

      Si je peux me fermettre, c'est ton usage personnel. C'est pas parce que tu n'en as pas l'utilité (ou que c'est nouveau) que c'est une forcement une "feature useless". Vu l'adoption, ça m'étonnerais que l'init change dans deux piges.
      PAM et SELinux ça doit équiper pas mal de monde à en croire distrowatch: tout ceux qui utilisent fedora, opensuse, centos, pclinuxos (mandriva et mageia?).
      Quand à savoir ce que ça apporte: je t'invite a lire plus en détail cette dépêche (rien que le fait d'avoir des scripts d'init propres et faciles à gérer sur des distro majeurs, ça devrait être un argument de poids)

      • [^] # Re: Lapin compris

        Posté par . Évalué à  -1 .

        PAM et SELinux ça doit équiper pas mal de monde

        Équiper n'est pas forcement utiliser. Telnet et apache sont sur la majorité des distributions, mais un utilisateur sur un ordinateur de bureau (c'est moche) ne va pas vraiment les utiliser.

        Quand à savoir ce que ça apporte: je t'invite a lire plus en détail cette dépêche

        Je l'ai lu et je dis: oui il y a des améliorations (meilleur suivi des PID, scripts plus simples…) qui cassent beaucoup de choses et j'espère que ce que l'on gagne vaut plus que ce que l'on perd.

        des scripts d'init propres et faciles à gérer

        Les scripts actuels marchent et ne sont pas dur à gérer. Je ne pense pas qu'ils changent tous les jours ni qu'il y est un besoin urgent de changer ça. c'est pourquoi amha, on n'est pas obligé de se depêcher.

        • [^] # Re: Lapin compris

          Posté par (page perso) . Évalué à  10 .

          Il y a des distributions qui installent de façon standard telnet (sic) et apache sur un ordinateur de bureau ?

    • [^] # Re: Lapin compris

      Posté par . Évalué à  10 .

      J'ai l'impression que c'est un jouet et que dans 2 ans on nous dira "ah bien non, en fait on va utiliser le system42 qui est mieux". Il y a de plus en plus de nouveautés poussées dans les distributions sans but réel.

      A la vue des gains que cela apporte, ce n'est pas un jouet pour moi, et je ne pense pas être le seul. Je ne conteste pas qu'il y ait un effet de mode, je me fiche pas mal du temps de démarrage sur mes serveurs; mais j'attends certaines choses avec impatience.

      En particulier:

      • la récupération de stdout et stderr est un problème récurrent, ainsi que le code de retour lorsque quelque chose ne démarre pas. J'y suis confronté plusieurs fois par an et je me suis retrouvé plus d'une fois à trafiquer les scripts de démarrage.

      • modifier les paramètres d'un service; sous debian on peut ajouter un paramètre au lancement dans certains paquets via un fichier dans /etc/defaults; comme ce n'est pas le cas pour tous, je dois modifier un script de 300 lignes pour ajouter cette variable; qui est perdu à chaque mise à jour.

      Pour l'avenir, j'ignore si une version 42 encore mieux sortira dans dix ans ou dans un an; mais je ne pense pas que ce soit une raison de se priver de ce que systemd apporte. systemd nous montrera peut-être qu'il faut aller dans une autre direction, ou que l'on peut encore améliorer certaines choses; mais cela ne se verra pas en restant dans l'état actuel.

      Meilleure intégration avec PAM et SELinux -> je n'utilise pas

      Je suis curieux de savoir quelle distribution tu utilises pour te passer de PAM ?

      • [^] # Re: Lapin compris

        Posté par . Évalué à  3 .

        Je suis curieux de savoir quelle distribution tu utilises pour te passer de PAM ?

        J'utilise Slackware. Lors de la sortie de la 13.1, il y avait eu une discussion à propos de PAM et le seul exemple d'utilisation sortie était d'empêcher le petit frère de la copine d'utiliser l'ordinateur la nuit.

    • [^] # Re: Lapin compris

      Posté par (page perso) . Évalué à  1 .

      J'ai du mal à comprendre les réels bonus. Oui, c'est mieux d'avoir moins de PID et une meilleure traçabilité mais est-ce que cela oblige vraiment à faire un système qui ne tourne que sous linux en faisant fi de la compatibilité avec les autres ?

      Ce n'est pas parce que tu n'y vois pas d'utilité qu'il n'y en a pas. Les usages que tu fais de ta distro ne reflète sûrement pas la majorité des utilisateurs (pas plus que les miens d'ailleurs). Concernant la compatibilité, il est temps que linux évolue et se passe de tout ça. C'est bien joli de vouloir un truc qui fonctionne sur tous les OS, mais pourquoi on se passerait des cgroups, de kms et autres juste pour assurer de la compatibilité ? Lennart n'est d'ailleurs absolument pas contre, il dit juste que personnellement il ne s'en occupera pas. Pour ceux que ça dérange, envoyez un patch !

      • [^] # Re: Lapin compris

        Posté par . Évalué à  10 .

        Il n'y a pas besoin de systemd pour utiliser les "cgroups, kms et les autres".
        Après, refaire le système d'init, je suis pas contre, mais si pour une fois Lennart pouvait nous sortir un projet bien conçu et bien fait comme il faut, en séparant la table de la choucroute et en rendant le truc compréhensible, modulaire et adaptable au souhait de tout les administrateurs, même ceux qui ne sont pas d'accord avec lui, moi je veux bien.

    • [^] # Re: Lapin compris

      Posté par (page perso) . Évalué à  4 .

      est-ce que cela oblige vraiment à faire un système qui ne tourne que sous linux en faisant fi de la compatibilité avec les autres ?

      Les BSD peuvent utiliser launchd qui a été porté sous FreeBSD lors d'un Google summer of code en 2005.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Lapin compris

        Posté par (page perso) . Évalué à  5 .

        Les BSD peuvent utiliser launchd qui a été porté sous FreeBSD lors d'un Google summer of code en 2005.

        Euh, pourquoi pas un init System V tant que vous y êtes !

        Que systemd ne soit pas portable, ça n'embête que Debian (pour kFreeBSD). On a déjà un truc différent qui est simple, stupide et qui marche.

        Pour qu'un tel système d'init soit intégré sur un BSD, il faudrait vraiment que ça apporte quelque chose de plus. Tu ne changes pas les habitudes des gens juste parce que "saimieux". À mon avis, launchd n'avait aucune chance d'être intégré dans FreeBSD (ouf).

        • [^] # Re: Lapin compris

          Posté par (page perso) . Évalué à  2 .

          launchd n'avait aucune chance d'être intégré dans FreeBSD

          Arf, je croyais que c'était FreeBSD qui avait initié le portage lors d'un Google summer of code? C'est Apple?

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: Lapin compris

            Posté par (page perso) . Évalué à  6 .

            Arf, je croyais que c'était FreeBSD qui avait initié le portage lors d'un Google summer of code? C'est Apple?

            FreeBSD c'est pas Ubuntu ou OpenBSD qui eux ont la chance d'avoir un chef éclairé. Il faut qu'il y ait un consensus pour adopter les choses. Qu'il y ait un gsoc ne veut pas dire que se sera intégré dans le système. Y'a eu plusieurs gsoc qui n'ont eu aucune suite. Y'en a même un qui a été commité puis supprimé (le portage du sensor framework d'OpenBSD, en raison des cris de Poul-Henning Kamp qui n'en voulait pas).

            Je maintiens que ça n'avait aucune chance, et oui c'est pas très cool pour la personne qui a bossé dessus...

    • [^] # Re: Lapin compris

      Posté par (page perso) . Évalué à  10 .

      Bref casser un standard pour ça…

      Quel standard exactement? Celui d'upstart, d'openrc, du système d'init de ArchLinux, de sysv ?

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: Lapin compris

        Posté par . Évalué à  1 .

        POSIX ? On a déjà eu le débat ici.

        Une des forces de linux que je cite souvent à mes amis, c'est qu'il est stable et utilise des standards. Les applications similaires sont souvent capables de communiquer entre elles et si on tag ses photos avec le logiciel X, le logiciel Y pourra récupérer ces tags contrairement à windows où les applications ont tendance à développer chacune son format pour garder prisonnier ses utilisateurs.

        Une dernière chose à propos de Systemd. Sur ce site j'ai entendu beaucoup de gens troller après le serveur X, le système de son, les drivers graphiques, les environnements de bureau, les suites offices, le shell, les pages man, le noyau etc. Mais je n'ai jamais entendu râler après le système d'init.

        • [^] # Re: Lapin compris

          Posté par (page perso) . Évalué à  2 .

          POSIX ? On a déjà eu le débat ici.

          Il ne casse pas le standard POSIX, il ne le respecte pas. Ça n'a rien à voir.

          Mais je n'ai jamais entendu râler après le système d'init.

          Et? Les gens qui râlent ici ne râlent pas parce qu'il plante, juste pour ce qu'il fera.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: Lapin compris

          Posté par (page perso) . Évalué à  10 .

          POSIX ?

          Une des forces de linux que je cite souvent à mes amis, c'est qu'il est stable et utilise des standards.

          Franchement ... tu as déjà réussi a faire fonctionner un script d'init de debian sur fedora ?

          Indice ... :
          ls /sbin/start-stop-daemon
          ls: impossible d'accéder à /sbin/start-stop-daemon: Aucun fichier ou dossier de ce type

          Prendre "standard" comme argument pour les scripts d'init, c'est un peu fort ...

    • [^] # Re: Lapin compris

      Posté par . Évalué à  -1 .

      hum ...

      Lapine comprise

      Trop difficile de resister... ==> []

    • [^] # Re: Lapin compris

      Posté par . Évalué à  -3 .

      Un démarrage plus rapide -> j'utilise la mise en veille et l'hibernation

      Moi pas. Ça me fait une raison suffisante de l'utiliser.

      Meilleure intégration avec PAM et SELinux -> je n'utilise pas et j'aimerai savoir si quelqu'un les utilise vraiment. Je veux dire un particulier hein.

      Ça m'étonnerait que tu n'utilises pas PAM, vu que c'est une des briques de base de Linux. Quant à SELinux, si justement le système d'init s'y intègre mieux, ce sera peut-être l'occasion de s'y mettre.

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

      • [^] # Re: Lapin compris

        Posté par (page perso) . Évalué à  7 .

        Ça m'étonnerait que tu n'utilises pas PAM, vu que c'est une des briques de base de Linux

        Slakware fonctionne sans pam. Pam m'a rien de nécessaire. Il existe d'autres moyen de gérer l'authentification. Pam n'a par ailleurs rien à voir avec Linux. FreeBSD, NetBSD, Solaris, Mac OS X par exemple l'utilisent également. Ça fait partie du standard XSSO.

      • [^] # Re: Lapin compris

        Posté par . Évalué à  2 .

        Ça m'étonnerait que tu n'utilises pas PAM, vu que c'est une des briques de base de Linux.

        Perdu, slackware arrive très bien à vivre sans PAM et ses problèmes de sécurités.

        Quant à SELinux, si justement le système d'init s'y intègre mieux, ce sera peut-être l'occasion de s'y mettre.

        Rien ne t'empêche de l'utiliser. Après, vu la page wikipedia, si une personne en a vraiment besoin, elle n'aura pas entendu systemd pour l'utiliser.

  • # Quoi ? Il faut créer plein de processus ?

    Posté par . Évalué à  9 .

    J'aime beaucoup systemd, et le boulot de Lennart Poettering en général (même si je conçois que beaucoup de ses projets ont été amenés à gêner pas mal de monde dans l'utilisation quotidienne de systèmes libres).

    Ceci dit, je commence à en avoir ras-le-derrière de cet argument. Je cite : "Tout le système de démarrage SysVinit est basé sur des scripts qui lancent des commandes externes. D’après Lennart cette approche est condamnée à être lente.".

    1) grep, awk, cut, sed, etc. pourraient (souvent) être remplacés par des primitives du shell, et on éviterait de lancer des processus. Si les primitives manquent au shell par défaut de la distro, c'est peut-être plus intelligent de l'implémenter (ou d'utiliser un langage dynamique plus puissant, genre Python/Perl/Ruby/votre lubie) que de faire pêter du C ?

    2048 processus echo prennent 5 secondes :

    bash-3.2$ time sh -c 'for id in {1..2048}; do /bin/echo $id; done > /dev/null'
    real    0m5.453s
    user    0m1.374s
    sys     0m3.542s
    

    2048 echo de Bash prennent 50ms :

    bash-3.2$ time sh -c 'for id in {1..2048}; do echo $id; done > /dev/null'
    real    0m0.051s
    user    0m0.041s
    sys     0m0.007s
    

    2) J'ai écrit en 2 minutes un micro-benchmark (pourri, comme tout benchmark). Un processus qui crée un enfant puis attend qu'il termine. Cet enfant crée lui-même un enfant puis attend qu'il termine. Le tout récursif, 2048 fois (donc 0 parallélisation, et on se retrouve avec 2049 de ces processus en simultané...).

    Dans une machine virtuelle sur un laptop avec processeur basse consommation, l'exécution prend un total de 11 ms.

    $ grep ^Pid /proc/self/status; time ./forking; grep ^Pid /proc/self/status
    Pid:    15451
    real    0m0.011s
    user    0m0.002s
    sys     0m0.009s
    Pid:    15548
    

    Si vous doutez de ma capacité à écrire 10 lignes de code, vous pouvez vérifier sur [https://github.com/pcarrier/stuff/blob/master/fun/forking.c].

    systemd apporte des fonctionnalités géniales, mais de grâce, arrêtons d'utiliser la performance comme argument pour l'introduction de larges binaires.

    • [^] # Re: Quoi ? Il faut créer plein de processus ?

      Posté par . Évalué à  5 .

      Je réalise que les PIDs n'augmentent pas "assez", que je ne vois pas immédiatement pourquoi, et que j'ai l'air bien con.

      • [^] # Re: Quoi ? Il faut créer plein de processus ?

        Posté par . Évalué à  10 .

        $ cat /etc/security/limits.d/90-nproc.conf 
        ## Default limit for number of user's processes to prevent
        ## accidental fork bombs.
        ## See rhbz #432903 for reasoning.
        
        *          soft    nproc     1024
        

        Fedora 15
    • [^] # Re: Quoi ? Il faut créer plein de processus ?

      Posté par . Évalué à  6 .

      Mon petit doigt me dit que ton système est suffisamment malin pour ne pas décharger puis recharger en mémoire le shell à chaque tour de boucle, contrairement au cas réel où plusieurs binaires auront été lancés entre deux itérations. À mes yeux, ton benchmark ne vaut effectivement rien. Pour que Python vaille le coup, j'imagine qu'il faudrait une architecture comprenant une machine virtuelle tournant en permanence dans laquelle serait ajoutés les scripts de lancement, sinon on passerait beaucoup de temps à charger/décharger toute la machinerie Python.

      systemd apporte des fonctionnalités géniales, mais de grâce, arrêtons d'utiliser la performance comme argument pour l'introduction de larges binaires.

      Il y a d'autres arguments dans la dépêche comme le lancement à la demande d'un deamon ou bien son redémarage, par exemple après une mise à jour, sans perte des données en attente de traitement.

    • [^] # Re: Quoi ? Il faut créer plein de processus ?

      Posté par . Évalué à  6 .

      Si vous doutez de ma capacité à écrire 10 lignes de code, vous pouvez vérifier sur [https://github.com/pcarrier/stuff/blob/master/fun/forking.c].

      Dans ce cas il est de bon ton de vérifier les valeurs de retour des fonctions que l'on utilise ;)

      Upon successful completion, fork() returns a value of 0 to the child
      process and returns the process ID of the child process to the parent
      process. Otherwise, a value of -1 is returned to the parent process, no
      child process is created, and the global variable errno is set to indi-
      cate the error

      Je suis assez d'accord avec toi sur le cote perf, par contre microbenchmarker fork() n'a pas tellement de sens. Ca ne correspond pas a grand chose.

    • [^] # Re: Quoi ? Il faut créer plein de processus ?

      Posté par . Évalué à  10 .

      Si vous doutez de ma capacité à écrire 10 lignes de code, vous pouvez vérifier sur [https://github.com/pcarrier/stuff/blob/master/fun/forking.c].

      Ton test ne fait que le fork; il manque pas mal de travail. Il faudrait tester avec un exec qui va parcourir PATH pour trouver le bon fichier, qui va modifier le mappage mémoire, qui va faire la résolution dynamique des librairies, charger les locales, lire sur stdin, écrire sur stdout, sortir, enfin coté fils il faut encore lire le résultat.

      Le test d'une série me semble pas mal, genre partir de n=0 et lancer 2048 fois "bc" en lui passant "n+2".

      En shell ça donne ça:

      $  time bash -eu -c 'N=0; for I in $(seq 2048); do N=$(echo "$N + 2" | bc); done; echo $N'
      4096
      real    0m3.352s
      user    0m0.940s
      sys     0m2.390s
      

      Ce qui fait 3.3 secondes chez moi.

    • [^] # Re: Quoi ? Il faut créer plein de processus ?

      Posté par . Évalué à  2 .

      Sauf que tu fais que des forks, pas un seul exec et un script shell, ca fait plein de exec dans tous les sens :-)

  • # Login et multi-siège

    Posté par (page perso) . Évalué à  4 .

    D'après les derniers posts sur son blog, Lennart Poettering prévoit de gérer le login (gdm) et le multi-siège (une tour et plusieurs écrans / claviers / souris).

    • [^] # Re: Login et multi-siège

      Posté par . Évalué à  9 .

      Encore un effort, il va pouvoir rajouter un editeur de texte et puis reinventer les Lisp machines.

    • [^] # Re: Login et multi-siège

      Posté par . Évalué à  3 .

      bye bye kdm ?

      • [^] # Re: Login et multi-siège

        Posté par . Évalué à  10 .

        Soit je suis un grand naïf, soit vous tirez des conclusions hâtives (faille trollo-temporelle, des semaines de sept vendredis).
        La seul mention de gdm sur la page de freedesktop (puisque tl;dr):

        Uses:
        If you are writing a display manager (like gdm), then enumerate all seats via logind's D-Bus interface, and subscribe to new seats being created. Then, spawn an X server and login screen on each seat showing up.

        Usage:
        Si vous écrivez un gestionnaire de session (par exemple gdm), alors énumérer les sièges à travers logind de l'interface D-Bus, et souscrire aux nouveaux sièges créés. Alors, démarrer un serveur X et un écran de connexion sur chacun de ces sièges.

        Rien qui suggère l'éviction de kdm, ni un asterisque pointant sur un plan de domination mondial, ni même la mention du démarrage d'une machine expresso. Par contre ça papote multi-siège, un truc relou à mettre en place et qui me serait bien utile.

        • [^] # Re: Login et multi-siège

          Posté par . Évalué à  1 .

          Rien qui suggère l'éviction de kdm, ni un asterisque pointant sur un plan de domination mondial,

          Sauf si on regarde ici. Il propose quand même de mettre systemd comme dépendance à GNOME. On a quitté le domaine de l'init pour venir sur celui du bureau.

          • [^] # Re: Login et multi-siège

            Posté par . Évalué à  10 .

            Il propose quand même de mettre systemd comme dépendance à GNOME.

            Finalement, ça m’ennuierait moins que la dépendance de Gnome à pulseaudio (du même auteur, pour ceux qui ne suivent pas).

            Enfin grâce à Gnome 3, le pire pour moi maintenant, ce serait que quelque chose dont j’ai besoin dépende de Gnome...

            Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

    • [^] # Re: Login et multi-siège

      Posté par . Évalué à  2 .

      et si on utilise pas de dm ? on fait comment ?

  • # Petits PIDs

    Posté par . Évalué à  9 .

    Une métrique intéressante est le PID du premier processus utilisable une fois le système démarré. Avec les noyaux actuels, cela donne une bonne idée du nombre de processus lancés. Amorcer le système, lancer un terminal, faire « echo $$ » : sous Linux, le PID est 1823, sous Mac OS X c’est 154.

    Cette métrique souffre d'un biais : les OS n'incrémentent pas le PID de la même façon entre 2 forks. Sous Ubuntu, j'ai constaté un incrément moyen de 48, sous Solaris de 16, sous MacOS de 2 (le tout modulo 65536 probablement). On ne peut donc pas conclure grand chose de echo $$.

    • [^] # Re: Petits PIDs

      Posté par . Évalué à  2 .

      Au lieu de me moinsser, ne serait-il pas plus intéressant de contre-argumenter, par exemple avec les formules magiques d'incrémentation de pid si quelqu'un les connait ?

    • [^] # Re: Petits PIDs

      Posté par (page perso) . Évalué à  2 .

      Chez moi, c'est choisi au hasard (mais ce doit être une option du noyau).

      DLFP >> PCInpact > Numerama >> LinuxFr.org

    • [^] # Re: Petits PIDs

      Posté par . Évalué à  4 .

      Suite à une remarque d'un relecteur, j'ai vérifié en écrivant l'article.

      http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.39.y.git;a=blob;f=kernel/pid.c;h=57a8346a270e07702e21d7bab15303427bf2fce0;hb=HEAD

      Ligne 167 dans la fonction alloc_pidmap(struct pid_namespace *pid_ns)

      pid = last + 1;
      if (pid >= pid_max)
          pid = RESERVED_PIDS;
      

      La suite de la fonction détermine si pid est utilisé dans ce namespace pour chercher une autre valeur.

      La fonction alloc_pid un peu plus bas, fait une boucle dans la pile des namespaces pour affecter un pid dans chaque namespace défini en utilisant alloc_pidmap

      Donc le kernel à la vanille incrémente bien de 1 le PID pour chaque nouveau processus, en tout cas tant qu'on n'a pas dépassé pid_max qui vaut de mémoire 0x8000 en mode normal.

    • [^] # Re: Petits PIDs

      Posté par . Évalué à  0 .

      Ça incrément seulement de 5 ici:

      grep Pid /proc/self/status
      
      • [^] # Re: Petits PIDs

        Posté par . Évalué à  7 .

        Comme déjà proposé je vous invite à refaire vos tests d'une manière correcte. Ça pue que:
        - Des processus sont lancés en parallèle
        - Une appli qui tourne créée des threads (selon les OS un thread bouffe un pid ou non)
        - Votre environnement est configuré d'une telle manière qu'il lance des commandes entre deux invocations
        - Ton système a fait le tour des pids et applique la règle du +1 en sautant les cases occupées, t'es tombé dedans.

        Reboot en passant /bin/sh comme processus d'init. Enchaine X fois ta commande et tu verras que les pids sont bêtement incrémentés.

        La dernière référence qu'il manquait est ici: http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/os/pid.c#160

        Après vérification du code des trois systèmes nommés (Linux/darwin/opensolaris) tous font +1. Il suffit d'aller vérifier le code et/ou de refaire les tests convenablement.

  • # double fork

    Posté par . Évalué à  5 .

    Il devrait être capable de couper complètement un service. Cela semble facile mais est en réalité très difficile. Sous UNIX, un processus qui fait un double fork (le programme se relance lui‐même en tâche de fond) sort complètement de la supervision du processus qui l’a lancé. Prenons par exemple un script CGI lancé par un serveur Web. Lorsqu’il fait un double fork, il devient orphelin et est rattaché au processus de PID 1. L’arrêt du serveur Web ne le concerne pas, et aucun script système n’est en mesure de le retrouver automatiquement pour le couper.

    Ce n'est pas tout-à-fait exact :

    un processus devient orphelin lorsque son père se termine (il est alors adopté par init).

    Si un processus A fait un "double-fork", entendez par là qu'il fait un fils B puis B fait un petit-fils C, alors C n'est pas orphelin tant que B n'est pas mort ; ça n'a rien à voir avec le fait de faire un double fork.

    En pratique, les démons font souvent un fork pour changer de PID et se détacher du terminal ; puis ils font des fils spécilisés sur des traitements et des connexions. Ces fils sont donc des petits-fils du démon initial, mais ils ne sont pas orphelins puisque le démon forké est vivant ! Mais avec un PID différent du PID initial.

    Comme tout ceci est difficile à suivre (pas tant que ça grâce à pstree), la notion de groupe de processus peut simplifier certaines opérations, en effet.

  • # très bon article !

    Posté par . Évalué à  3 .

    Merci pour cet article bien écrit, très didactique et fort instructif !

  • # euh

    Posté par . Évalué à  1 .

    ne pas demarrer les services inutiles c'est pas plus simple surtout si en s'en sert pas ?
    quand a avahi un des devellopeurs est lennart...

    • [^] # Re: euh

      Posté par (page perso) . Évalué à  4 .

      Si tu ne t'en sert jamais, autant ne pas les installer. Si tu t'en sers parfois, c'est beaucoup plus pratique de ne pas avoir à démarrer manuellement le service avant d'imprimer ou de tester ta page web.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: euh

        Posté par . Évalué à  -9 .

        ça doit prendre 2secondes a demarrer un service donc bon...

        • [^] # Re: euh

          Posté par (page perso) . Évalué à  7 .

          Ça dépend qui doit le faire... déjà comprendre ce que c'est (ben oui, sous WinTruc et MacMachin, l'utilisateur fait simplement "Imprimer...").

        • [^] # Re: euh

          Posté par . Évalué à  5 .

          Multiplie par le nombre de services à démarrer, puis compare à la patience de l'utilisateur…

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

  • # Pourquoi faire simple quand on peut faire compliqué ?

    Posté par . Évalué à  10 .

    Bon alors j'ai pas approfondi plus que ça, mais j'ai un peu de mal à comprendre en quoi tout ça ne serait pas réalisable sans casser la compatibilité:

    • démarrer un service à la demande ? Y'avait pas un déjà truc qui s'appelait inetd ?
    • eviter de démarrer 1000 processus ? y'a qu'à utiliser un shell plus complet, comme un bon vieux lisp des familles.
    • suivre les processus? J'ai du mal avec ça, mais il y a pas un système de log sous linux?
    • contrôler le contexte du service ? je ne vois pas ce qui ne pourrait pas être fait sous un shell, avec quelques librairies.

    Moi je vois approcher (déjà rien que le style des noms utilisés) un linux qui ressemble de plus en plus à MacOSX, c'est -à-dire un système totalement opaque dans lequel il devient impossible au nom spécialiste de comprendre ce qui se passe. Ce qui fait la force de linux, c'est sa très grande bidouillabilité, et c'est via le principe de base des unix: des outils simples qui font peu de chose mais qui le font bien.

    • [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?

      Posté par (page perso) . Évalué à  9 .

      démarrer un service à la demande ? Y'avait pas un déjà truc qui s'appelait inetd ?

      Ben si mais c'est dommage d'avoir deux méthodes complémentaires pour démarrer un service. C'est plus la situation actuelle qui est compliquée. Il faut aller voir à plusieurs endroit pour savoir si un service va démarrer (/etc/init.d, /etc/init (pour upstart), /etc/(x)inetd.conf, ...).

      comme un bon vieux lisp des familles

      C'est clair que tout deviendrait plus clair en lisp (ou pas).

      suivre les processus? J'ai du mal avec ça, mais il y a pas un système de log sous linux?

      Le nombre de fois que j'ai du faire des kill(all) parce que samba, squid, apache, ... n'était pas arrêté complètement lorsque je lui demandais ... franchement si ca marche enfin ca sera une grosse avancée !

      Personnellement j'ai plus l'impression que cela va simplifier le processus de démarrage : plus rapide, fichier de conf clair et lisible (contrairement au script de démarrage actuel), tous les services gérés par un unique système, ...

    • [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?

      Posté par . Évalué à  9 .

      On reprends:

      démarrer un service à la demande ? Y'avait pas un déjà truc qui s'appelait inetd ?

      Je parle justement de inetd dans la dépêche; pour t'éviter de tout lire: oui, inetd le fait pour les sockets Internet; mais n'est pas utilisé dans ce mode (généralement il lance une instance par requête). Il semblerait que certaines implémentations existe pour le faire sur les sockets de type fichier; mais je n'en ai jamais vu. Rien n'existe pour les messages SystemV à ma connaissance, ni sur la présence de fichiers dans un répertoire. systemd propose une solution qui généraliste le démarrage à la demande à un maximum de solutions techniques.

      eviter de démarrer 1000 processus ? y'a qu'à utiliser un shell plus complet, comme un bon vieux lisp des familles.

      On pourrait utiliser emacs ? Le soucis c'est qu'à nouveau, on sort du normalisé. Les shells plus puissant sont généralement bien plus lourds parce qu'ils ont aussi beaucoup de développements liés à l'interactivité qui n'ont aucun intérêt dans un script.

      suivre les processus? J'ai du mal avec ça, mais il y a pas un système de log sous linux?

      Si, bien sur; mais je ne connais aucun système qui va rediriger les logs des services. Généralement la tache en est confiée au service.

      contrôler le contexte du service ? je ne vois pas ce qui ne pourrait pas être fait sous un shell, avec quelques librairies.

      A nouveau, rien n'est impossible; mais il n'existe pas de lanceur de service qui s'occupent à la fois de modifier l'user, les groupes, les cgroups, les capacités, le chroot, les logs, le contexte selinux, les limits, le umask et que sais-je encore. A chaque fois ça passe par l'écriture ou le bidouillage du script de démarrage qui n'a généralement pas été prévu pour. On se retrouve avec 150 scripts très semblables dans /etc/init.d dont aucun n'est complet.

      Dans ce sens, systemd permet de passer en chroot un service qui n'avait pas été prévu pour, simplement en modifiant son fichier de configuration.

    • [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?

      Posté par . Évalué à  5 .

      'est -à-dire un système totalement opaque dans lequel il devient impossible au nom spécialiste de comprendre ce qui se passe.

      Si j'ai bien compris ce que tu dis madame Michu pour tout comprendre, il lui suffit de comprendre inted, le lisp, le système de log sous linux et maitriser le shell.

      Peux tu me dire les acquis nécessaires pour être considéré comme un spécialiste sous linux, parce que là j'ai du mal ;)

      • [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?

        Posté par . Évalué à  1 .

        'est -à-dire un système totalement opaque dans lequel il devient impossible au nom spécialiste de comprendre ce qui se passe.

        Si j'ai bien compris ce que tu dis madame Michu pour tout comprendre, il lui suffit de comprendre inted, le lisp, le système de log sous linux et maitriser le shell.

        Peux tu me dire les acquis nécessaires pour être considéré comme un spécialiste sous linux, parce que là j'ai du mal ;)

        rholala si on ne peut plus s'amuser à mettre les mains dans le cambouis pour bidouiller son pingouin où est le fun ? et puis quoi de plus flexible qu'un langage de script pour déclarer l'initialisation de ses services, les trucs spécifiques à chaque plateforme tout ça ?

        bon ça reste sympa parce que la démarche est trollifère mais à ce compte là quitte à proposer ce genre d'innovation pourquoi pas ne pas faire péter le trollomètre en intégrant systemd au noyau ?

        • [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?

          Posté par . Évalué à  2 .

          Si vraiment la foultitude de paramètre proposés par systemd pour lancer un daemon est pas suffisante pour toi (sachant que ya quand même des trucs assez tordus genre limiter les flux d'IO disque et réseaux, ou des trucs plus classiques mais pas communs non plus genre le chroot), tu peux toujours faire en sorte que systemd appelle un script wrapper dans lequel tu mettras tout les machins d'initialisation que tu veux, au lieu d’appeler directement le binaire du service.

      • [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?

        Posté par . Évalué à  2 .

        Si j'ai bien compris ce que tu dis madame Michu pour tout comprendre, il lui suffit de comprendre inted, le lisp, le système de log sous linux et maitriser le shell.

        D'une part ce sont des compétences réutilisables, d'autres part elles s’acquièrent au fil de l'eau. De plus si dès qu'on est pas un spécialiste on est une madame Michu c'est que tu a vraiment une vision fermée.

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

        • [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?

          Posté par . Évalué à  1 .

          Pauvre Mme Michu, elle est aux geeks ce que le "kevin" est au joueurs de jeux vidéos: Un terme péjoratif (bien souvent opposé au geek poilu). Je propose l'utilisation de Mr Duchmol pour s'invectiver, c'est bien moins sexiste . Pour ce qui est de "mettre les mains dans le cambouis", c'est très relatif. Pour certain, c'est écrire un pilote, tandis que pour d'autre, lancer un terminal pour installer un logiciel (ou pire... c'est cliquer sur paramètres systèmes).

          Pour en revenir au sujet, il serait peut être temps de se rendre compte que "bureau" n'est ni "embarqué" ni "serveur" et quoi qu'il en soit, il suffit d'un paramètre au noyau pour changer d'init. Il sera toujours possible de creer le sien de toute pièce (même en brainfuck si vous voulez).
          Les distributions (à quelques exceptions prés) sont de toute façon, déjà segmentées de la sorte et cela n'a jamais empêché qui que ce soit d'hacker du matos pour y coller du GNU/Linux. Il s'agit d'avoir des distributions (orientées bureau) simples et efficaces pour l'utilisateur moyen, pas d'acquérir des compétences en vue d'une embauche dans une SSII.

          • [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?

            Posté par . Évalué à  7 .

            C'est juste, sauf que, dans la réalité, on constate qu'une innovation censée être "Claude Michu friendly", poussée par des développeurs qui trollent en expliquant que leur truc est nécessaire pour conquérir le marché du Desktop, se retrouvent dans des distros qui ne visent absolument pas Michu.

            Du genre, la suppression du raccourci fort pratique Ctrl + Alt + Backspace sous Xorg, qui est également supprimé par défaut sous Debian. C'est cool de virer une combinaison que les utilisateurs de Ubuntu ne savent pas utiliser et sur laquelle ils risquent d'appuyer par erreur, c'est moins cool de désappointer les power-users qui la connaissent et sont obligés de la remettre quand on la fait sauter.

            Si on a un systemd "pour le desktop" qui vient contaminer tous les services Linux, même les distros geek-friendly vont se retrouver avec ce blob qui va devenir in-virable sans complications.

            Qu'on facilite la vie à l'utilisateur lambda, en proposant, en plus, des fonctionnalités adaptées à un usage de bureau pour non spécialiste, c'est très bien. Qu'on intègre ça au coeur du système en en faisant le comportement par défaut, c'est sale.

            THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

            • [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?

              Posté par . Évalué à  2 .

              Qu'on facilite la vie à l'utilisateur lambda, en proposant, en plus, des fonctionnalités adaptées à un usage de bureau pour non spécialiste, c'est très bien. Qu'on intègre ça au coeur du système en en faisant le comportement par défaut, c'est sale.

              Ça devrait être un comportement configurable. Si je reprends l'exemple du raccourci clavier CTRL + ALT + SUPPR, on peut imaginer plusieurs jeux de raccourcis préréglés pour le bureau. Par défaut on utilise celui de Madame Michu, mais on peut choisir celui d'Éric le geek.

              Il y a quelques années j'avais installé une distribution — Mandrake je crois — qui avait le bon goût de me demander le niveau de sécurité voulu (de paranoïaque à utopiste). On rencontre aussi couramment sur le web des sites qui ont un moteur de recherche scindé en deux interfaces : rapide ou approfondi.

              Pourquoi ne pas demander à l'utilisateur son degré d'aisance avec les ordinateurs au lieu de le supposer ou de l'ignorer. Avec cette information ou peut décider de verrouiller/déverrouiller (ajouter/supprimer) des fonctionnalités, changer des comportements, pré-installer des paquets.

              Plus le degré de maîtrise est proche de zéro plus on simplifie et on restreint le comportement de la machine. Au degré le plus élevé il n'y a pas de contrainte.

              Cette idée est difficile à réaliser j'en conviens. Comment et quels degrés distinguer ? Quels comportements sont les bons pour chacun ? Faut-il les réunir dans une même distribution ou créer une distribution (dérivée) par degré ?

            • [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?

              Posté par . Évalué à  -4 .

              Aaah le troll sur la suppression du ctrl+alt+backspace (qui n'est pas une idée de Poettring que je sache). Je lui ai toujours préféré un SIGTERM, voir un retour en init3. Les goûts et les couleurs me dira-t-on.

              Mais est-ce que la sérendipité prévaudrait dans le libre? Faut-il définir un problème avant de proposer une innovation? Les mainteneurs des distros sont-ils forcement des décérébrés?. Les 80% de râleurs forment 20% des utilisateurs si le principe de Pareto s'applique.

              Pour ce cas particulier, la masse n'en a pas l'usage et les poseurs-youzeurs savent comment le rétablir en un rien de temps.
              De toute façon les environnements de bureau récents sont des bloats (et non des blobs que j'ai toujours assimilés à du SALE, du proprio). Un kikoo-tiling-manager (- Tu fais quoi pendant les vacances? - J'installe un tiling-manager) ou black/open/osefbox (compilé sur un quad-core qui idle 98% du temps) ce n'est pas non plus une solution.
              "A tout problème complexe, il existe une solution simple et elle est forcément mauvaise"

Suivre le flux des commentaires

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