Évolutions techniques de systemd

Posté par Sébastien Koechlin le 02 août 2011 à 17:14. Modéré par baud123. Licence CC By‑SA.

Étiquettes :

144

août

2011

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

Processus de PID 1

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

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 ;
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)

A ← B (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] ; 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 (A ← B).

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 :

une note pour expliquer pas à pas les modifications nécessaires du code et de la configuration ;
une note décrivant un cas pratique avec CUPS ;
la page de manuel « daemon (7) ».

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 ?

Aller plus loin

Page du projet systemd (909 clics)
En savoir plus sur systemd (615 clics)
Comparatif de SysVinit, Upstart et Systemd par Lennart Poettering (722 clics)

# Merci pour le journal

Posté par fabricius le 02 août 2011 à 17:40. Évalué à 10.

Je ne dirais qu'une chose: on croirait du patrick_g!
- [^] # Re: Merci pour le journal
  
  Posté par Alexandre COLLIGNON (site web personnel) le 02 août 2011 à 19:05. É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 bubar🦥 (site web personnel) le 02 août 2011 à 20:48. É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 bubar🦥 (site web personnel) le 02 août 2011 à 20:53. É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 bubar🦥 (site web personnel) le 02 août 2011 à 20:59. Évalué à 4.
    
    Bref systemD permet d'être "bureau" sans rien empêcher d'autre. Facilement.
- [^] # Re: Merci pour le journal
  
  Posté par Rafael (site web personnel) le 03 août 2011 à 14:41. É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 nico_bobo le 03 août 2011 à 15:23. Évalué à 2.
  
  Entièrement d'accord. Je ne m'étais jamais vraiment intéressé à systemd, et bien c'est fait.
# localisation

Posté par coïn le 02 août 2011 à 17:42. É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 Spack le 02 août 2011 à 17:50. É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 daemontux le 03 août 2011 à 18:01. É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 zebra3 le 09 août 2011 à 14:33. É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
- [^] # Commentaire supprimé
  
  Posté par Anonyme le 03 août 2011 à 10:54. Évalué à 6.
  
  Ce commentaire a été supprimé par l’équipe de modération.
# troll mode

Posté par skeespin (site web personnel) le 02 août 2011 à 17:44. Évalué à -10.

TODO

Implement services.msc utility for linux
# Merci

Posté par Michel H le 02 août 2011 à 17:52. É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 Michel H le 02 août 2011 à 17:54. Évalué à 1.
  
  Arff
  s#ce passe#se passe#
- [^] # Re: Merci
  
  Posté par jigso le 02 août 2011 à 18:09. É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 Michel H le 02 août 2011 à 18:16. É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 etenil le 02 août 2011 à 18:28. É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 herodiade le 04 août 2011 à 01:35. É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 BB le 04 août 2011 à 14:37. É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 ZeroHeure (site web personnel) le 04 août 2011 à 15:28. É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 BB le 04 août 2011 à 18:37. É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 BB le 04 août 2011 à 21:29. É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 Sébastien Koechlin le 05 août 2011 à 09:23. Évalué à 9.
        
        Si j'essaye de résumer les deux solutions
        
        Solution à la demande
        
        lancer le service à la demande
        
        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 rogo le 02 août 2011 à 19:05. É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 BAud (site web personnel) le 02 août 2011 à 22:48. Évalué à 3.
      
      Tu aurais les traces des différents traitements lancés au démarrage (si possible avant / après).
      Je suppose que bootchart2 fonctionne encore ? comme ce que j'avais regardé l'année dernière : http://cookerspot.tuxfamily.org/wikka.php?wakka=Blog20100329BootChart2 ?).
      - [^] # Re: Merci
        
        Posté par Frédéric COIFFIER le 04 août 2011 à 18:15. Évalué à 5.
        
        Sinon, une astuce pour mesurer les temps de démarrage de chaque service avec systemd (en remplacement de bootchart) :
        http://www.tux-planet.fr/analyser-les-temps-de-demarrage-de-votre-os-avec-systemd/
  - [^] # Re: Merci
    
    Posté par daemontux le 03 août 2011 à 18:30. É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 Grunt le 02 août 2011 à 19:18. É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 Guillaume D. le 02 août 2011 à 19:24. Évalué à 4.
    
    telnet ?
    
    ok ->[]
  - [^] # Re: Merci
    
    Posté par needs le 02 août 2011 à 21:05. Évalué à 1.
    
    Rien ne t'empêche de le lancer toi même.
  - [^] # Re: Merci
    
    Posté par JGO le 02 août 2011 à 21:46. É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 __o le 02 août 2011 à 21:54. Évalué à 2.
      
      Tu pourras certainement désactiver le lancement de SSH comme tu le fais actuellement.
      - [^] # Re: Merci
        
        Posté par JGO le 02 août 2011 à 22:07. É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 Jerome le 02 août 2011 à 22:12. Évalué à 4.
        
        Un paquet openssh-server n'est pas forcement installe par defaut si ?
        
        [^] # Re: Merci
        
        Posté par ckyl le 02 août 2011 à 22:50. É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 JGO le 02 août 2011 à 23:23. É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.
        
        http://littre.reverso.net/dictionnaire-francais/definition/%C3%A2nerie/2519
        
        [^] # Re: Merci
        
        Posté par gnumdk (site web personnel) le 03 août 2011 à 00:09. É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 Serge Julien le 03 août 2011 à 00:18. Évalué à 0.
        
        s/suggèrerais/suggérerais/
        
        (À pinailleur, pinailleur et demi :-)
        
        Sinon, d'accord avec toi sur le fond...
        
        [^] # Re: Merci
        
        Posté par JGO le 03 août 2011 à 11:15. É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 fleny68 le 07 août 2011 à 22:50. Évalué à 2.
        
        s/enseignée/recommandée/
        
        On n'enseigne plus l'orthographe dans l'éducation nationale.
        
        [^] # Re: Merci
        
        Posté par Zylabon le 03 août 2011 à 02:25. É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 Grunt le 03 août 2011 à 01:14. É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 Mali (site web personnel) le 03 août 2011 à 13:27. É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 flagos le 03 août 2011 à 17:55. Évalué à 8.
        
        reload est tres utile pour ne pas avoir d'interruption de service
        
        [^] # Re: Merci
        
        Posté par DLFP est mort le 04 août 2011 à 10:13. É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 herodiade le 04 août 2011 à 00:59. É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 gik le 02 août 2011 à 19:29. É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 vladislav askiparek le 02 août 2011 à 20:20. É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 lolop (site web personnel) le 03 août 2011 à 09:48. É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.
    
    Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
    - [^] # Re: Merci
      
      Posté par lolop (site web personnel) le 03 août 2011 à 10:12. Évalué à 3.
      
      ça prend... du temps
      
      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
  - [^] # Re: Merci
    
    Posté par Jak le 07 août 2011 à 07:17. É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 kaliko (site web personnel) le 02 août 2011 à 19:28. É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 Grunt le 03 août 2011 à 01:16. É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 Anthony Bourguignon (site web personnel) le 03 août 2011 à 10:54. É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 Sébastien Koechlin le 03 août 2011 à 11:45. É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 kaliko (site web personnel) le 04 août 2011 à 13:56. É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 Sylvestre Ledru (site web personnel) le 04 août 2011 à 10:53. Évalué à 2.
  
  http://packages.qa.debian.org/s/systemd.html
  - [^] # Re: systemd / Debian
    
    Posté par kaliko (site web personnel) le 04 août 2011 à 13:49. É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 reno le 04 août 2011 à 17:28. É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 Laurent A. le 04 août 2011 à 22:26. É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 ZeroHeure (site web personnel) le 07 août 2011 à 02:35. É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 j_kerviel le 02 août 2011 à 19:38. É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 gik le 02 août 2011 à 20:26. É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 theocrite (site web personnel) le 02 août 2011 à 21:28. É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 __o le 02 août 2011 à 21:52. É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 gik le 02 août 2011 à 23:25. Évalué à 2.
      
      J'ai pas pu expérimenter, mon home et léger et en btrfs mais meme si c'est pas bloquant comme bogue, saymeuch'
      C'est l'objet d'un rapport https://bugzilla.redhat.com/show_bug.cgi?id=679492
      Un patch est proposé sur http://lists.freedesktop.org/archives/systemd-devel/2011-June/002654.html
    - [^] # Re: Diverses remarques
      
      Posté par claudex le 03 août 2011 à 11:51. Évalué à 6.
      
      On peut imaginer une barre de progression à ce moment-là.
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Diverses remarques
    
    Posté par Antoine le 05 août 2011 à 13:07. É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 bubar🦥 (site web personnel) le 02 août 2011 à 21:03. Évalué à 4.
  
  fsck n'a pas d'avenir.
  une granularité "atomique" des snapshots sera plus rapide ET plus efficace.
  - [^] # Re: Diverses remarques
    
    Posté par theocrite (site web personnel) le 02 août 2011 à 21:29. É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 bubar🦥 (site web personnel) le 02 août 2011 à 21:51. Évalué à 4.
      
      en attendant
      
      On continue avec l'existant qui fonctionne (très) bien ?
      - [^] # Re: Diverses remarques
        
        Posté par Gabin le 03 août 2011 à 03:44. É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 Pierre Tramonson le 03 août 2011 à 14:04. Évalué à 10.
      
      On leur dit fsck !
  - [^] # Re: Diverses remarques
    
    Posté par Antoine le 05 août 2011 à 13:09. É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 bubar🦥 (site web personnel) le 05 août 2011 à 15:29. É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 Antoine le 06 août 2011 à 14:25. É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 bubar🦥 (site web personnel) le 06 août 2011 à 18:20. É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 M le 02 août 2011 à 21:05. É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 ckyl le 02 août 2011 à 21:21. É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 Mildred (site web personnel) le 03 août 2011 à 22:26. É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 Juke (site web personnel) le 06 août 2011 à 10:24. É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 Zylabon le 03 août 2011 à 02:30. É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 Anthony Bourguignon (site web personnel) le 03 août 2011 à 10:58. É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 DLFP est mort le 03 août 2011 à 11:41. É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 Zarmakuizz (site web personnel) le 04 août 2011 à 09:20. É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 Zylabon le 05 août 2011 à 11:20. É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 fearan le 09 août 2011 à 10:48. É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 Zylabon le 17 août 2011 à 10:22. É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 Anonyme le 03 août 2011 à 11:26. Évalué à 4.
      
      Il y a une solution très simple : ne pas lancer fsck.
      
      Ben oui, ReiserFS fonctionne bien :)
    - [^] # Re: Diverses remarques
      
      Posté par claudex le 03 août 2011 à 11:57. Évalué à 4.
      
      C'est un problème pour tous les systèmes sur batteries (portable, onduleurs…)
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
- [^] # Re: Diverses remarques
  
  Posté par Grunt le 03 août 2011 à 01:21. É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 Arthur Accroc le 03 août 2011 à 11:05. É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.
  
  « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
  - [^] # Re: Diverses remarques
    
    Posté par daemontux le 03 août 2011 à 18:50. É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 geb le 02 août 2011 à 20:35. É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 Pierre Bourdon le 02 août 2011 à 20:42. É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 geb le 07 août 2011 à 08:21. Évalué à 2.
    
    Merci. Si tu as un lien je suis preneur. Je n'ai rien trouvé.
    - [^] # Re: utilisation des cgroups ?
      
      Posté par Sébastien Koechlin le 08 août 2011 à 09:22. É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 Guillaume D. le 02 août 2011 à 21:27. Évalué à -8.

salut

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

dans 1 an ....
- [^] # Chez moi, si.
  
  Posté par Arthur Accroc le 03 août 2011 à 11:13. É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.
  
  « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
  - [^] # Re: Chez moi, si.
    
    Posté par Nonolapéro le 03 août 2011 à 11:22. É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 Arthur Accroc le 03 août 2011 à 11:29. Évalué à 2.
      
      Il faut indiquer à systemd qu’il doit lancer ton gestionnaire de connexion au démarrage.
      
      Par exemple : systemctl enable gdm.service
      
      « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
      - [^] # Re: Chez moi, si.
        
        Posté par Guillaume D. le 03 août 2011 à 18:49. É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 gik le 04 août 2011 à 07:48. É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 Nonolapéro le 05 août 2011 à 23:18. É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 Arthur Accroc le 06 août 2011 à 02:42. É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.
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
        
        [^] # Re: Combien ?
        
        Posté par Nonolapéro le 06 août 2011 à 09:54. É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 Arthur Accroc le 06 août 2011 à 18:03. É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
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Passionnant !

Posté par Jarvis le 02 août 2011 à 21:28. É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 Altor le 02 août 2011 à 22:24. É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 bubar🦥 (site web personnel) le 02 août 2011 à 22:40. É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 JGO le 02 août 2011 à 22:46. É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é.
  - Choosing between portability and innovation https://lwn.net/Articles/429597/
  - https://linuxfr.org/news/un-entretien-avec-lennart-poettering
  - [^] # Re: Lapin compris
    
    Posté par Altor le 02 août 2011 à 23:15. Évalué à 7. Dernière modification le 02 août 2011 à 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 Laurent A. le 03 août 2011 à 00:51. Évalué à 3.
      
      Il a oublié le cas XFree86-Xorg ?
  - [^] # Re: Lapin compris
    
    Posté par Grunt le 03 août 2011 à 01:24. É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 herodiade le 04 août 2011 à 01:28. É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 gik le 02 août 2011 à 22:51. É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 Altor le 02 août 2011 à 23:31. É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 lolop (site web personnel) le 03 août 2011 à 10:07. Évalué à 10.
      
      Il y a des distributions qui installent de façon standard telnet (sic) et apache sur un ordinateur de bureau ?
      
      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
- [^] # Re: Lapin compris
  
  Posté par Sébastien Koechlin le 03 août 2011 à 11:01. É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 Altor le 03 août 2011 à 11:50. É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 Anthony Bourguignon (site web personnel) le 03 août 2011 à 11:17. É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 Batchyx le 03 août 2011 à 22:03. É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 ZeroHeure (site web personnel) le 03 août 2011 à 21:41. É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 Patrick Lamaizière (site web personnel) le 03 août 2011 à 23:58. É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).
    
    les pixels au peuple !
    - [^] # Re: Lapin compris
      
      Posté par ZeroHeure (site web personnel) le 07 août 2011 à 02:20. É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 Patrick Lamaizière (site web personnel) le 07 août 2011 à 17:19. É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...
        
        les pixels au peuple !
- [^] # Re: Lapin compris
  
  Posté par claudex le 04 août 2011 à 01:50. É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 ?
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Lapin compris
    
    Posté par Altor le 04 août 2011 à 13:18. É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 claudex le 04 août 2011 à 13:34. É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.
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
    - [^] # Re: Lapin compris
      
      Posté par GnunuX (site web personnel) le 07 août 2011 à 10:11. É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 warwick le 05 août 2011 à 12:18. Évalué à -1.
  
  hum ...
  
  Lapine comprise
  
  Trop difficile de resister... ==> []
- [^] # Re: Lapin compris
  
  Posté par zebra3 le 09 août 2011 à 15:32. É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 Joris Dedieu (site web personnel) le 09 août 2011 à 18:31. É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 Altor le 09 août 2011 à 23:52. É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 Pierre Carrier le 03 août 2011 à 00:11. É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 Pierre Carrier le 03 août 2011 à 00:21. É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 Spack le 03 août 2011 à 00:33. É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 Laurent A. le 03 août 2011 à 01:03. É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 ckyl le 03 août 2011 à 01:17. É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 Sébastien Koechlin le 03 août 2011 à 11:14. É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 cedric le 04 août 2011 à 18:15. É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 Frédéric Massot (site web personnel) le 03 août 2011 à 00:26. É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).
- freedesktop multiseat
- phoronix multiseat
- [^] # Re: Login et multi-siège
  
  Posté par Littleboy le 03 août 2011 à 03:48. É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 Hojo le 03 août 2011 à 20:15. Évalué à 4.
    
    Et il changera le nom pour emacs
- [^] # Re: Login et multi-siège
  
  Posté par kowalsky le 03 août 2011 à 12:36. Évalué à 3.
  
  bye bye kdm ?
  - [^] # Re: Login et multi-siège
    
    Posté par gik le 03 août 2011 à 17:21. É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 Altor le 04 août 2011 à 18:43. É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 Arthur Accroc le 05 août 2011 à 05:14. É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...
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
- [^] # Re: Login et multi-siège
  
  Posté par modr123 le 05 août 2011 à 10:26. Évalué à 2.
  
  et si on utilise pas de dm ? on fait comment ?
  - [^] # Re: Login et multi-siège
    
    Posté par navaati le 09 août 2011 à 12:56. Évalué à 2.
    
    Eh bah tu configure. On parle d'ajouter des possibilités, là, calmos.
# Petits PIDs

Posté par gato le 03 août 2011 à 08:54. É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 gato le 03 août 2011 à 09:25. É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 ckyl le 03 août 2011 à 10:31. Évalué à 6.
    
    http://lxr.linux.no/#linux+v3.0/kernel/pid.c#L162
    
    En général tu as trois options pour implémenter ca:
    - Tu incrémentes un compteur (linux)
    - Tu fais un random pour éviter certaines attaques de réutilisation de pid (openBSD, linux avec grsec)
    - Tu découpes ton int en plusieurs espaces pour optimiser la contention par processeur. (pas de système modernes qui font ca AFAIK)
    
    Donc je serais toi je referais mes tests.
    - [^] # Re: Petits PIDs
      
      Posté par ckyl le 03 août 2011 à 10:37. Évalué à 7.
      
      Et pour OS X c'est la: http://fxr.watson.org/fxr/source/bsd/kern/kern_fork.c?v=xnu-1456.1.26;im=excerpts#L1068
- [^] # Re: Petits PIDs
  
  Posté par DLFP est mort le 03 août 2011 à 09:27. É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 Sébastien Koechlin le 03 août 2011 à 11:25. É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 __o le 03 août 2011 à 14:25. Évalué à 0.
  Ça incrément seulement de 5 ici:
```
grep Pid /proc/self/status
```
  - [^] # Re: Petits PIDs
    
    Posté par ckyl le 03 août 2011 à 15:10. É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 gato le 03 août 2011 à 09:06. É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.
- [^] # Re: double fork
  
  Posté par ckyl le 03 août 2011 à 11:16. Évalué à 3.
  
  Le principe c'est justement de tuer immédiatement le processus intermédiaire...
  
  http://svnweb.freebsd.org/base/head/lib/libc/gen/daemon.c?revision=205165&view=markup
  
  Et si tu cumules ça plusieurs fois tu te retrouves avec l'impossibilité de retrouver les processus.
- [^] # Re: double fork
  
  Posté par Sébastien Koechlin le 03 août 2011 à 11:29. Évalué à 3.
  
  Ce n'est pas tout-à-fait exact
  
  Le terme double-fork dans son sens littéral est effectivement trompeur. Je n'ai pas voulu expliquer en détail le mécanisme qu'on entends par là pour éviter d'allonger un article déjà très long. Merci de l'avoir fait dans les commentaires.
# très bon article !

Posté par krapule le 03 août 2011 à 09:59. Évalué à 3.

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

Posté par modr123 le 04 août 2011 à 11:40. É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 claudex le 04 août 2011 à 12:27. É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.
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: euh
    
    Posté par modr123 le 04 août 2011 à 13:36. Évalué à -9.
    
    ça doit prendre 2secondes a demarrer un service donc bon...
    - [^] # Re: euh
      
      Posté par lolop (site web personnel) le 04 août 2011 à 15:25. É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...").
      
      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
    - [^] # Re: euh
      
      Posté par zebra3 le 09 août 2011 à 15:46. É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 fleny68 le 07 août 2011 à 23:18. É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 GnunuX (site web personnel) le 08 août 2011 à 09:34. É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 Sébastien Koechlin le 08 août 2011 à 09:35. É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 Kangs le 08 août 2011 à 21:13. É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 tyoup le 08 août 2011 à 23:54. É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 navaati le 09 août 2011 à 13:12. É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 barmic le 09 août 2011 à 18:33. É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.
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
      
      Posté par gik le 13 août 2011 à 01:37. É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 Grunt le 14 août 2011 à 03:30. É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 Anonyme le 14 août 2011 à 15:01. É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 Grunt le 14 août 2011 à 15:52. Évalué à 1.
        
        Par défaut on utilise celui de Madame Michu, mais on peut choisir celui d'Éric le geek.
        
        Tss tss, sexiste, c'est "Claude Michu" et "Dominique Geek" ;)
        
        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
        
        [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
        
        Posté par Anonyme le 14 août 2011 à 16:38. Évalué à -4.
        
        Merci Grunt l'androgyne d'en profiter pour placer une petite blague vexatoire à teneur politiquement correcte pour faire monter ton karma, au lieu d'une réponse utile.
        
        [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
        
        Posté par Grunt le 14 août 2011 à 17:25. Évalué à 2.
        
        Merci de m'en avoir donné l'occasion en insérant un sous-entendu sexiste dans ton commentaire.
        
        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
        
        [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
        
        Posté par Anonyme le 14 août 2011 à 17:39. Évalué à -3.
        
        T'es à côté de la plaque. Je voulais juste faire une rime et donner un prénom bien terre à terre au geek pour qu'il arrête de se prendre pour un Dieu du PC.
        
        [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
        
        Posté par gik le 16 août 2011 à 18:10. É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"
        
        [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
        
        Posté par barmic le 16 août 2011 à 23:07. Évalué à 3.
        
        Il t'en reste un peu pour moi ? Elle a l'air bonne.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
        
        Posté par gik le 17 août 2011 à 00:27. Évalué à -2.
        
        Humpf non. Je l'ai foutu à la poubelle après m’être relu.