LinuxFr.org a déjà publié quelques articles à propos de systemd, sans entrer trop dans les détails des améliorations techniques.
On trouve en particulier un entretien avec son auteur, Lennart Poettering, et un journal contestant la qualité et les dépendances du code.
L’arrivée de systemd provoque pas mal de remous, justifiés ou non. On peut citer l’objectif « Linux only » affiché par l’auteur, les multiples dépendances et en particulier celle de D-Bus, la personnalité de l’auteur et la qualité de ses réalisations précédentes, le périmètre de responsabilité de systemd
(gdm) et probablement de nombreux autres points.
Cet article a pour objectif de passer en revue les évolutions techniques et les objectifs de systemd
. Les autres questions citées ci‐dessus ne sont pas injustifiées (en tout cas, pas toutes), mais sont en dehors du périmètre fixé.
L’article se base essentiellement sur les présentations de Lennart Poettering publiées sur son site en particulier, certains paragraphes sont des traductions un peu condensées de sa présentation initiale.
Merci aux relecteurs : Davy, Spack, npa.
Sommaire
- État des lieux
- Performances
- Gains fonctionnels
- Second interlude : Upstart et les autres systèmes
- Systemd
- Écrire un service
- Conclusion
É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
oubluetooth.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
etstderr
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 desystemd
. - 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 queshutdown
oureboot
. Les ordres sont transmis àsystemd
via D-Bus. Il prend en charge égalementkexec
qui permet de relancer le noyau Linux. - Il gère
utmp
etwtmp
, 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
etHugeTBLfs
sont gérés viaautofs
, ce qui évite d’avoir à les configurer enroot
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 lereadahead
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 parsystemd
; - 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 (916 clics)
- En savoir plus sur systemd (621 clics)
- Comparatif de SysVinit, Upstart et Systemd par Lennart Poettering (725 clics)
# Merci pour le journal
Posté par fabricius . É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) . É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🦥 (Mastodon) . É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🦥 (Mastodon) . Évalué à 9.
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🦥 (Mastodon) . É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) . É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 . É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 . É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 . É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 . É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 :
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 . É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 . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
# troll mode
Posté par skeespin (site web personnel) . Évalué à -10.
TODO
Implement services.msc utility for linux
# Merci
Posté par Michel H . É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 . Évalué à 1.
Arff
s#ce passe#se passe#
[^] # Re: Merci
Posté par jigso . É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 . É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 . É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 . Évalué à 10.
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 . É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 . É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 . É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 . É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 . Évalué à 9.
Si j'essaye de résumer les deux solutions
Solution à la demande
Solution pré-chargement
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 . É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) . É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 . É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 . É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 . É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. . Évalué à 4.
telnet ?
ok ->[]
[^] # Re: Merci
Posté par needs . Évalué à 1.
Rien ne t'empêche de le lancer toi même.
[^] # Re: Merci
Posté par JGO . É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 . Évalué à 2.
Tu pourras certainement désactiver le lancement de SSH comme tu le fais actuellement.
[^] # Re: Merci
Posté par JGO . É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 . Évalué à 4.
Un paquet openssh-server n'est pas forcement installe par defaut si ?
[^] # Re: Merci
Posté par ckyl . É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 . Évalué à -6.
1) Je n'ai pas critiqué systemd en soi.
2) Je n'ai pas dit de quoi que ce soit que était « de la merde ».
3) J'apprécierais que tu évites de critiquer mes propos en les qualifiant d'« âneries pareils ». En effet je suis très sensible aux fautes d'orthographes je m'attendais à ce que tu les qualifies plutôt d'« âneries pareilles ». Je te suggèrerais en outre de placer l'adjectif en position antéposée, « de pareilles âneries », comme dans l'exemple rapporté par le dictionnaire d'Émile Littré*. Ou, au choix, de ne pas insulter les gens du tout.
J'ai critiqué précisément un exemple cité de configuration de ce système, qui est de mettre un démarrage automatique sur une action ayant une implication forte sur la sécurité, ssh étant utilisé dans un contexte qui ne profite que de façon très limitée d'un tel automatisme, qui en revanche peut créer un trou de sécurité.
Après, je me doute bien que les gens éduqués savent désactiver les fonctions qui ne leur sont pas utiles.
[^] # Re: Merci
Posté par gnumdk (site web personnel) . É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 . Évalué à 0.
s/suggèrerais/suggérerais/
(À pinailleur, pinailleur et demi :-)
Sinon, d'accord avec toi sur le fond...
[^] # Re: Merci
Posté par JGO . É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 . Évalué à 2.
s/enseignée/recommandée/
On n'enseigne plus l'orthographe dans l'éducation nationale.
[^] # Re: Merci
Posté par Zylabon . Évalué à 2.
L’île de Man c'est pas en Afrique du sud ;)
Please do not feed the trolls
[^] # Re: Merci
Posté par Grunt . É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) . É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 . Évalué à 8.
reload est tres utile pour ne pas avoir d'interruption de service
[^] # Re: Merci
Posté par DLFP est mort . É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 . É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 . É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 . É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) . É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.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Merci
Posté par lolop (site web personnel) . Évalué à 3.
ça prend... du temps
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Merci
Posté par Jak . É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) . Évalué à 6.
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 . É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) . É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 . É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:
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) . Évalué à 2.
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) . Évalué à 2.
http://packages.qa.debian.org/s/systemd.html
[^] # Re: systemd / Debian
Posté par kaliko (site web personnel) . É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 . É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. . É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 . É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 . Évalué à 10.
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.
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 :)
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 . É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) . Évalué à 6.
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 ?
Quelques Téra de DD, ça prend quand même un peu de temps (tout le monde n'a pas un SSD de 80Go).
Ah ok.
[^] # Re: Diverses remarques
Posté par __o . É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 . É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 . É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 . Évalué à 9.
Encore faut-il savoir qu'un fsck est en cours quand le système a l'air bloqué.
[^] # Re: Diverses remarques
Posté par bubar🦥 (Mastodon) . É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) . É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🦥 (Mastodon) . Évalué à 4.
On continue avec l'existant qui fonctionne (très) bien ?
[^] # Re: Diverses remarques
Posté par Gabin . Évalué à 3.
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 . Évalué à 10.
On leur dit fsck !
[^] # Re: Diverses remarques
Posté par Antoine . É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🦥 (Mastodon) . É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 . Évalué à 2.
Ça fait des années que je n'ai pas vu un système de fichiers cassé, donc c'est difficile de répondre.
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🦥 (Mastodon) . Évalué à -5.
ha non, rien :p
ha ben rien non plus :)
[^] # Re: Diverses remarques
Posté par M . Évalué à 2.
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 . É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) . É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) . É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 . É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) . É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 . É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) . É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 . É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 . É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 . É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 . É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 . É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 . Évalué à 5.
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),
startx, c'était mieux.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Diverses remarques
Posté par Arthur Accroc . Évalué à 0.
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 . Évalué à 2.
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 . É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 . É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 . É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 . É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
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. . É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 . É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 . É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 . É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. . É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 . É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 . É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 . Évalué à 2.
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 . É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 . É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 »...) :
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Passionnant !
Posté par Jarvis . É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 . É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🦥 (Mastodon) . É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 . Évalué à 4.
Si tu as lu les interviews de Poettering, tu sais qu'il est à fond pour développer pour linux sans s'occuper de la portabilité.
[^] # Re: Lapin compris
Posté par Altor . É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) :
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. . Évalué à 3.
Il a oublié le cas XFree86-Xorg ?
[^] # Re: Lapin compris
Posté par Grunt . É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 . Évalué à 3.
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 . É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 . Évalué à -1.
É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.
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.
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) . Évalué à 10.
Il y a des distributions qui installent de façon standard telnet (sic) et apache sur un ordinateur de bureau ?
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Lapin compris
Posté par Sébastien Koechlin . Évalué à 10.
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.
Je suis curieux de savoir quelle distribution tu utilises pour te passer de PAM ?
[^] # Re: Lapin compris
Posté par Altor . Évalué à 3.
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) . Évalué à 1.
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 . É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 . Évalué à 4.
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) . Évalué à 5.
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 . Évalué à 2.
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) . Évalué à 6.
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 . Évalué à 10.
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 . É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 . Évalué à 2.
Il ne casse pas le standard POSIX, il ne le respecte pas. Ça n'a rien à voir.
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) . Évalué à 10.
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 . Évalué à -1.
hum ...
Lapine comprise
Trop difficile de resister... ==> []
[^] # Re: Lapin compris
Posté par zebra3 . Évalué à -3.
Moi pas. Ça me fait une raison suffisante de l'utiliser.
Ç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) . Évalué à 7.
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 . Évalué à 2.
Perdu, slackware arrive très bien à vivre sans PAM et ses problèmes de sécurités.
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 . É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 :2048
echo
de Bash prennent 50ms :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.
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 . É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 . Évalué à 10.
Fedora 15
[^] # Re: Quoi ? Il faut créer plein de processus ?
Posté par Laurent A. . É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.
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 . Évalué à 6.
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 . Évalué à 10.
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:
Ce qui fait 3.3 secondes chez moi.
[^] # Re: Quoi ? Il faut créer plein de processus ?
Posté par cedric . É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) . Évalué à 4.
D'après les derniers posts sur son blog, Lennart Poettering prévoit de gérer le login (gdm) et le multi-siège (une tour et plusieurs écrans / claviers / souris).
[^] # Re: Login et multi-siège
Posté par Littleboy . É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 . Évalué à 4.
Et il changera le nom pour emacs
[^] # Re: Login et multi-siège
Posté par kowalsky . Évalué à 3.
bye bye kdm ?
[^] # Re: Login et multi-siège
Posté par gik . É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 . Évalué à 1.
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 . Évalué à 10.
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 . Évalué à 2.
et si on utilise pas de dm ? on fait comment ?
[^] # Re: Login et multi-siège
Posté par navaati . Évalué à 2.
Eh bah tu configure. On parle d'ajouter des possibilités, là, calmos.
# Petits PIDs
Posté par gato . Évalué à 9.
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 . É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 . É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 . É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 . É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 . É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)
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 utilisantalloc_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 . Évalué à 0.
Ça incrément seulement de 5 ici:
[^] # Re: Petits PIDs
Posté par ckyl . É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 . Évalué à 5.
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 . É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 . Évalué à 3.
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 . Évalué à 3.
Merci pour cet article bien écrit, très didactique et fort instructif !
# euh
Posté par modr123 . É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 . É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 . Évalué à -9.
ça doit prendre 2secondes a demarrer un service donc bon...
[^] # Re: euh
Posté par lolop (site web personnel) . É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...").
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: euh
Posté par zebra3 . É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 . É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é:
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) . Évalué à 9.
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, ...).
C'est clair que tout deviendrait plus clair en lisp (ou pas).
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 . Évalué à 9.
On reprends:
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.
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.
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.
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 . Évalué à 5.
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 . Évalué à 1.
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 . É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 . Évalué à 2.
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 . É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 . É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 . Évalué à 2.
Ç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 . Évalué à 1.
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 . É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 . É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 . É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 . É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 . É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 . Évalué à -2.
Humpf non. Je l'ai foutu à la poubelle après m’être relu.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.