Sylvain Blandel a écrit 258 commentaires

Le support natif de systemd par chaque package qui propose des scripts SysV

Actuellement, la plupart des paquets Debian sont uniquement prévus pour SysV. Si systemd est actif, il vient alors surcouche. L'objectif est de fournir systématiquement, en plus de la configuration et du script shell pour Sysv, une configuration et un exécutable ELF pour systemd.

D'après cette page du wiki Debian, il s'agirait, pour chaque paquet qui fournit un script dans le répertoire /etc/init.d, de fournir également un fichier .service dans le répertoire /usr/lib/systemd/system/

L'objectif semble atteignable : plusieurs distributions sont déjà passées à systemd. Les mainteneurs Debian peuvent s'inspirer (voir copier-coller) les fichiers .service des autres distributions. Cette possibilité est d'ailleurs clairement envisagée par un mainteneur Debian :

Adding a service file and dh-systemd support
[…] Then, search for a service file, either upstream or in other distributions such as Arch Linux, Fedora, Gentoo, etc. In case there is no service file yet, write one.

D'ici le gel de Debian 8, la version 7 de Red Hat Enterprise Linux aura vu le jour, et elle utilisera systemd par défaut. Les fichiers .service de RHEL 7 seront également une source d'inspiration pour les mainteneurs Debian.

si une API survit et s'avère utilisée, elle mérite que l'on s'y intéresse. Si elle crève dans son coin, on aura bien fait de ne pas s'y intéresser.

Et si elle survit parce que tu as utilisé cette API pour créer des technologies innovantes, pertinentes et efficaces ? Bin non, vu que tu n'auras rien fait, « l'interface n'était pas raisonnablement figée, alors j'attendais ». Tu laisses les autres décider quelles seront les technologies dominantes de demain.

La version 7 de Red Hat Enterprise Linux utilisera systemd, et systemd dépend des cgroups. Sachant que la maintenance de Red Hat Enterprise Linux peut s'étendre jusqu'à 13 ans, l'existence des cgroups me semble garantie pour quelques années

Gnome utilise certaines API de systemd mais ce sont des API qui peuvent être implémenter par n'importe quel système d'init, et Canonical les porte sur Upstart.

Il semble que tu as raison. Sur le wiki de Gnome, il est écrit :

the creation of the GNOME desktop experience […] focuses on a tightly-integrated desktop environment based on the GNOME Shell running on a GNU-based operating system with a Linux kernel.

Et à la section « Recommended components », il est écrit :

It is assumed and encouraged (but not required!) that distributions make use of the following technologies : Wayland, systemd.

Systemd est mentionné, mais pas Upstart. J'en déduis que « Gnome upstream » fonctionne naturellement avec systemd, mais pas avec Upstart. Ainsi, les distributions utilisant Upstart (comme Ubuntu) doivent fournir un travail supplémentaire pour utiliser Gnome.

« tes applications préférés vont arrêter de tourner sur ton système d'exploitation préféré »

Quelles sont ces applications qui, actuellement, ne nécessitent pas systemd, et qui, dans leurs versions futures, exigeront systemd ?

(ce n'est pas de l'ironie, les réponses m'intéressent sincèrement)

Sur ma bécane, je suis parvenu à remplacer cron par systemd. J'en ai fait un tutoriel : Remplacer cron par systemd

Qu'est-ce que le système d'initialisation aurait à faire dans /usr/lib ? Dans /lib, à la rigueur, et même là je trouverais encore ça anormal. Ça a tout à faire dans /bin au contraire, ou /sbin, à la rigueur.

Il y a eu des modifications à ce niveau-là sous Arch : /lib est devenu un lien symbolique vers /usr/lib. Le système d'initialisation peut donc être appelé par /usr/lib/systemd/systemd ou /lib/systemd/systemd

De plus, la totalité des binaires est maintenant installée dans /usr/bin ; en effet, les répertoires /bin, /sbin et /usr/sbin sont des liens pointant vers /usr/bin

Les explications sont ici.

/bin/systemd plutôt.

Sur Archlinux, le binaire /bin/systemd a disparu, il est remplacé par /usr/lib/systemd/systemd. J'ignore si cela est dû à la distribution, ou à une version récente de systemd.

De toute façon, /bin/init pointe vers /usr/lib/systemd/systemd. Ainsi, lorsque l'on ne précise pas de init= sur la ligne du noyau, on démarre sur systemd.

modifier la conf du noyau d'Arch et recompiler

Tu peux essayer le noyau LongTerm Stable d'Archlinux (le paquet s'appelle linux-lts).

À noter que c'est Debian qui maintient la version 3.2 du noyau : c'est la version utilisée par Wheezy, l'actuelle Debian stable. En effet, Ben Hutchings, le mainteneur de cette version, est membre de l'équipe noyau de Debian (autre lien).

Archlinux va prochainement adopter ce noyau en tant que noyau LTS (LongTerm Stable). Actuellement, c'est la version 3.0 de Linux qui est le noyau LTS.

La vidéo de la conférence Why Debian should (or should not) make systemd the default est disponible en ligne : basse qualité, haute qualité.

Deux autres conférences traitaient de systemd :

Making your package work with systemd.
Le diaporama de la présentation est disponible, de même que la vidéo (basse qualité, haute qualité)

systemd myths debunked !
Le diaporama de la présentation est disponible, de même que la vidéo en basse qualité.

Sur le site, les liens vers les vidéos sont incorrects. J'ai utilisé les bons liens pour ce post.

Le souci c'est qu'avec dd je vais avoir une image de la taille exacte du disque, c'est à dire 1 Tio non ?

Hum … je pense que oui. Ça va être embêtant.

Il me semble que tu t'es trompé dans l'utilisation de dd : le tutoriel n'utilise pas le disque /dev/sdb, mais la partition /dev/sdb1

Bonjour.

Effectivement, l'utilisation de dd pourrait être utile. Voir ce tutoriel : Récupérer les données d'un disque défectueux. Dans le tutoriel, la partition défectueuse est /dev/hda1 ; il faudra que tu remplaces cela par le nom des partitions de ton disque défectueux (/dev/sdb1, …).

Bon courage !

lorsque l'on programme, est-il possible de le faire "en aveugle"

Si tu estimes que les symboles de programmation sont mal placés, tu peux personnaliser ta keymap. Pour cela, deux possibilités :

1. La commande xmodmap

2. En modifiant directement la keymap. Sous Archlinux, les fichiers à modifier sont /usr/share/kbd/keymaps/i386/dvorak/fr-dvorak-bepo.map.gz (keymap pour les terminaux virtuels tty) et /usr/share/X11/xkb/symbols/fr (keymap de l'interface graphique). Sauvegarde puis modifie ces fichiers, puis fais-en une archive de même nom que l'original.

    

En procédant ainsi, j'ai intégré des smileys dans la keymap, pour les écrire directement. Cette page t'intéressera peut-être : Trucs et astuces sur bepo.fr.

Cet article du wiki t'intéressera peut-être : une introduction au contrôle du trafic réseau avec Linux.

Je fait des devis pour des pièces de rechange dans le ferroviaire.

Par hasard, tu ne travaillerais pas au Québec ?

quel est l'intérêt d'aller et venir entre console et X, vu que tu peux avoir un shell dans un terminal ?

Lorsque des logiciels « importants » de l'interface graphique doivent être mis à jour …

Hum … J'ai répondu à côté de la plaque.
Si on souhaite éteindre ces logiciels avant de les mettre à jour, on est obligé d'utiliser un tty (ce n'est pas un choix). Et il n'y a pas « d'aller et retour » entre le tty et X.

quel est l'intérêt d'aller et venir entre console et X, vu que tu peux avoir un shell dans un terminal ?

Lorsque des logiciels « importants » de l'interface graphique doivent être mis à jour (X, KDE, Qt, …), je préfère que ces logiciels soient stoppés durant la mise-à-jour. Dans ces cas-là, je ferme toutes les sessions graphiques, ainsi que le gestionnaire de connexion graphique lui-même. Et c'est depuis un tty que j'effectue les mises-à-jour.

cette manie des distribs de vouloir cacher les message de démarrages du noyau et des services au boot […] à chaque fois que je dois redémarrer une redhat ou une CentOS et que quelque chose se passe mal, je dois rebooter, interrompre le boot du grub, et modifier les options quiet et rhgb.

Sur les machines que tu administres, pourquoi ne pas supprimer définitivement les options quiet et rhgb dans le fichier de configuration de ton chargeur de démarrage ?

Concernant systemd : en cas de problème au démarrage, systemd peut ne démarrer que le strict minimum de services (c'est équivalent au runlevel 1 de SysV). Il suffit pour cela d'ajouter l'option systemd.unit=rescue.target à la ligne du noyau (pour être compatible avec l'existant, les alias single et 1 sont utilisables).

le code de systemd (intrinsèquement plus complexe, et testé sur une échelle infiniment moindre)

Comme systemd est utilisé (par défaut) par plusieurs distributions, la chasse aux bugs est mutualisée.

Je suis d'accord qu'un logiciel ayant plus de lignes de code a, potentiellement, des bugs plus nombreux, et je suis également d'accord que systemd est jeune. Mais il a un avantage : c'est un système d'init identique qui est utilisé par plusieurs distributions. Il y a ainsi plus d'utilisateurs susceptibles de découvrir ses bugs (par rapport à l'époque où chacune de ces distributions avait ses propres scripts d'init).

Sur redhat.com, on apprend que la version 7 de Red Hat Enterprise Linux utilisera systemd. L'entreprise Red Hat estime donc que systemd est suffisamment stable pour être lancé en production.

cela veut dire que même si les développeurs sont nombreux au final, la décision est faite par un seule personne (ou quelques uns) mais qui sont avec RH.

L'auteur principal de systemd a déjà répondu à ce point :

Myth: systemd is a Red-Hat-only project, is private property of some smart-ass developers, who use it to push their views to the world.

Not true. Currently, there are 16 hackers with commit powers to the systemd git tree. Of these 16 only six are employed by Red Hat. The 10 others are folks from ArchLinux, from Debian, from Intel, even from Canonical, Mandriva, Pantheon and a number of community folks with full commit rights. And they frequently commit big stuff, major changes. Then, there are 374 individuals with patches in our tree, and they too came from a number of different companies and backgrounds, and many of those have way more than one patch in the tree. […]

La réponse est très longue, elle est intégralement lisible dans le document The 30 Biggest Myths about systemd (c'est le mythe n°27, en bas de la page).

Pour revenir à l'argument avancé : l'employeur a toujours de l'influence sur ses employés. Si on suit l'argument, il faudrait que tous les « logiciels importants » soient développés par des personnes échappant à l'influence d'un employeur. Dans ce cas, comment ces développeuses/développeurs de « logiciels importants » gagneraient-ils leurs vies ?

Salut.

Utiliseras-tu Grub 1 ou Grub 2 ?
Grub 2 gère les disques partitionnés en GPT. J'ignore si Grub 1 le fait. Le reste de mon message est valable pour Grub 2.

---

j'utilise avant systemrescuecd et gparted
je choisis la table de partition gpt pour le disque système
je crée la partition non formatée de 1 mo pour le boot en début de disque
j'y ajoute le drapeau bios_grub

La méthode me semble bonne. Pour la partition en début de disque (sur laquelle tu mets le drapeau bios_grub), la taille de 1 Mo est peut-être juste. Chez moi, j'ai mis 32 Mo, mais j'ignore qu'elle est la taille minimale nécessaire.

au moment de l'installation du grub j'indique le chemin de cette partition de boot

Non, tu indiques seulement le disque (tu indiques /dev/sdX, et pas /dev/sdX1).

---

je voudrais savoir si des disques durs partitionnés en gpt et msdos peuvent bien cohabiter sur une machine

Je suppose que oui.

---

je sauvegarde mes partitions msdos avec partimage avant le changement de partitionnement
je repartitionne le disque système en gpt
pourrais je sans problèmes restaurer la totalité de mes partitions avec partimage sur ce même disque ?

Je ne connais pas partimage. Pour sauvegarder les données de mes partitions, j'utilise la commande cp -a :

# Pour faire la copie de sauvegarde :
cp  -a  /media/sdX3/*  /media/sdY4

# Pour restaurer les données :
cp  -a  /media/sdY4/*  /media/sdX3

Bien sûr, ceci est à adapter à ton schéma de partitionnement et au numéro de tes partitions.

je peux vous parrainer, vous gagnerez 60€ en tant que filleul

Vous aussi, vous gagnerez de l'argent. Sur le site internet de la banque en question, cette page mentionne une prime versée au parrain.

Ou-ouh ?
Freem ? T'es encore là ? :-)

Grub2 est devenu pénible à configurer, d'où mon passage à LILO

Arf ! 😄

Je me doutais un peu de ta réaction, mais c'est un choix réfléchi :)

N'y vois pas de malice de ma part, c'est juste que nos avis sont différents (et que j'adore utiliser les smileys en UTF-8 😞😐😊😄). Lorsque je l'utilisais, Lilo me semblait pénible à paramétrer car, pour modifier sa configuration, il fallait lancer un exécutable (le binaire lilo) après avoir modifié le fichier de conf. Je trouve Grub2 plus simple à paramétrer : on modifie le fichier de conf, on enregistre, point. La mauvaise réputation de Grub2 me paraît injustifiée.

Enfin, chacun ses besoins. Si Lilo te convient, tant mieux. 😊

Il me semble que, sous Debian, cron (et son copain anacron) sont installés par défaut,

Ça dépend.
Ils le sont si tu sélectionnes les outils de base lors de l'installation du système, mais il se trouve que c'est quelque chose que je ne fais plus depuis bien longtemps

C'est noté.

La quantité de RAM ne me semble pas avoir grand chose à voir avec la modernité par contre. Mais sa techno, si: la DDR3, ça va encore non? Il semble que la DDR4 soit prévue à la vente grand public pour 2015 après tout…).

Ça va m'être difficile de répondre, je suis un fossile, resté à la DDR2. 😊
Et effectivement, je voulais dire : la surconsommation de RAM causée par systemd me semble raisonnable, vu la quantité de RAM utilisée dans le matériel moderne.

Enfin bon, plutôt que de jouer avec les priorités des processus, le plus simple et le plus efficace reste de sélectionner des logiciels qui font ce qu'on leur demande, tout en étant moins gourmands.

Combien de temps passé à chercher les bons logiciels, à les tester, à les configurer ? Mais je reconnais que ta démarche permet d'apprendre, c'est plus instructif que de jouer avec la priorité des processus.

D'ailleurs, je me demande si cups+samba+sysVinit consomment autant que systemd seul? C'est une vraie question hein, vu que je n'utilise pas les 2 démons cités, je n'ai absolument aucune idée de leur consommation.

Je l'ignore. C'est vrai que, si systemd consomme 50 pour économiser 30, mon argument tombe à l'eau. 😊

je ne serais pas contre une solution de remplacement qui soit capable de lire les fichiers utilisés par systemd, mais qui n'apporte pas de dépendances dont je n'ai que faire. Et dont je ne suis manifestement pas le seul à n'avoir que faire: quand le sujet est abordé sur la ml de debian, je constate que je ne suis pas le seul a éprouver des réticences à installer dbus et autres truckit.

Lorsqu'il a conçu systemd, Lennart Poettering a choisi d'utiliser des briques déjà existantes : dbus, les truckit, etc. Conséquence de ce choix : systemd a de nombreuses dépendances. Si Lennart avait cloné toutes les briques nécessaires, et intégré ces clones dans le code de systemd directement, systemd n'aurait aucune dépendance aujourd'hui (ou très peu). Le package d'installation de systemd serait plus gros, mais systemd aurait exactement les mêmes fonctionnalités. Et aucune dépendance (ou très peu).

L'argument « systemd a trop de dépendances » n'existe qu'à cause des choix de conception de systemd : s'appuyer sur des logiciels existants, plutôt que de ré-inventer la roue.

Dans ta conception des choses, tu pourrais remplacer « systemd a trop de dépendances » par « Pour plus de lisibilité, le code de systemd est réparti entre plusieurs paquets à installer ».

D'ailleurs, une anecdote : systemd n'est plus dépendant de consolekit ! Dans la liste des dépendances de la version 202 de systemd, on ne trouve aucun truckit. Les fonctionnalités de consolekit ont été intégrées à systemd, dans un composant nommé systemd-logind. D'ailleurs, l'abandon de consolekit est confirmé sur la distribution qu'il ne faut pas nommer ☠