systemd version 216

Posté par  (site web personnel) . Édité par esdeem, Davy Defaud, ZeroHeure, ElChinese, Nils Ratusznik, Benoît Sibaud, Melkor73, palm123, BAud, Xavier Teyssier et patrick_g. Modéré par patrick_g. Licence CC By‑SA.
Étiquettes :
55
31
oct.
2014
Technologie

Le programme d’init systemd est sorti dans une nouvelle version. Par tradition, cette version ne se contente pas des habituelles corrections de bogues et modifications mineures, mais inclut de nouvelles options qui peuvent affecter tout le monde (sauf les irréductibles de *BSD, bien sûr). Cette dépêche présente un aperçu rapide des changements, ainsi qu’une traduction complète du journal des modifications. La dernière section décrit brièvement mon expérience de systemd sous Gentoo.

Sommaire

Les changements importants

Cette version confirme la vision de systemd comme le chef d’orchestre du système d’exploitation, englobant tous les domaines, pour le meilleur ou pour le pire.

Le réseau

De nombreuses nouveautés concernant le réseau ont été ajoutées dans cette version. Un nouvel outil, networkctl, permet d’obtenir les informations de configurations du réseau. Il est actuellement purement passif, mais devrait dans le futur permettre la configuration du réseau. En particulier, un effort a été apporté aux protocoles NTP, DNS et DHCP. Les deux premiers peuvent désormais utiliser plus d’informations provenant des requêtes DHCP. Les règles de nommage des interfaces ont aussi été changées. Si le noyau indique qu’il fournit un nom prédictible pour une interface, alors udev utilisera ce nom. Il s’agit ici de fournir à l’utilisateur une interface unique pour paramétrer et surveiller le réseau.

journald

journald peut désormais utiliser l’algorithme LZ4 pour la compression, afin d’améliorer ses performances. Par défaut, il ne transmet désormais plus ses données au démon syslog. Ce changement a été décidé puisque rsyslog n’attend plus cette transmission, mais pioche directement dans le journal. Enfin, la transmission du journal vers des machines distantes est facilitée grâce au nouvel outil systemd-journal-upload.

L’installation d’un nouveau système

Il est intéressant de noter l’apparition de l’utilitaire systemd-firstboot qui permet de configurer les informations de base d’un nouveau système. Voit‐on ici l’émergence d’un outil commun pour l’installation de nos distributions ? Dans le même état d’esprit, systemd_sysusers et /etc/machine-info disposent de nouvelles options permettant une plus grande flexibilité dans la configuration.

La traduction du journal des modifications

  • Désormais timedated ne lit plus les noms des implémentations de NTP autres que celle de systemd depuis les fichiers /usr/lib/systemd/ntp-units.d/*.list.
    Les autres implémentations de NTP doivent ajouter la ligne Conflicts=systemd-timesyncd.service à leur fichier unité pour prendre la priorité et remplacer l’implémentation de NTP de systemd qui est utilisée par défaut.

  • systemd-sysusers gagne un nouveau type de ligne, appelé r, pour configurer les gammes d’identifiants à allouer pour les utilisateurs et groupes système (UID et GID) .
    Les lignes de type u acceptent désormais une nouvelle colonne pour spécifier le répertoire HOME de l’utilisateur qui sera créé.
    En outre, systemd-sysusers peut lire les informations depuis l’entrée standard plutôt que depuis un fichier.
    C’est utile lorsque l’utilitaire est invoqué par les scripts de pré‐installation d’un paquet RPM (les scripts preinst) qui doivent créer l’utilisateur avant de pouvoir créer un fichier, puisque ces fichiers peuvent appartenir à ce nouvel utilisateur.
    Une nouvelle macro RPM appelée %sysusers_create_inline a été introduite pour réaliser cette opération.
    Enfin, systemd-sysusers met à jour le fichier /etc/shadow, ainsi que les bases de données des utilisateurs et des groupes.
    Ceci devrait améliorer la compatibilité avec certains outils tels que grpck.

  • Un certain nombre d’interfaces logicielles (API) du processus 1 (PID 1) peuvent désormais, sous certaines conditions, consulter PolicyKit pour donner l’accès à des clients ne disposant pas des privilèges nécessaires.
    L’authentification interactive n’est pour l’instant pas encore prise en charge. Cependant, cette fonctionnalité devrait être ajoutée dans le futur.

  • /etc/machine-info dispose désormais de nouveaux champs pour configurer l’environnement de déploiement de la machine ainsi que son emplacement.
    L’utilitaire hostnamectl a été mis à jour avec de nouvelles commandes pour modifier ces champs.

  • systemd-timesyncd a été mis à jour pour obtenir les informations à propos des serveurs NTP depuis systemd-networkd, qui peut lui‐même les obtenir à partir des requêtes DHCP.

  • systemd-resolved inclut désormais un cache DNS client qui possède une implémentation complète de la résolution de nom LLMNR.
    Un nouveau module NSS nss-resolve a été ajouté. Il utilise l’implémentation nss-dns de glibc pour résoudre les noms d’hôtes via systemd-resolved.
    Les noms d’hôtes, les adresses ou un enregistrement de ressource DNS peuvent être résolus via les API D-BUS de systemd-resolved.
    Contrairement au solveur interne de glibc, systemd-resolved est compatible avec des systèmes disposant de plusieurs interfaces :
    un serveur DNS et un cache sont maintenus pour chaque interface.
    Les requêtes sont envoyées simultanément sur chaque interface où un serveur DNS est configuré afin de correctement prendre en compte les réseaux privés virtuels (VPN) et les réseaux locaux (LAN) qui pourraient produire différents noms de domaines.
    systemd-resolved peut obtenir les informations des serveurs DNS depuis systemd-networkd automatiquement, qui peut les avoir obtenues à partir des informations DHCP.
    Un utilitaire systemd-resolve-host a été ajouté pour obtenir la méthode de résolution DNS du démon resolved.
    systemd-resolved implémente IDNA et choisit automatiquement l’encodage IDNA ou UTF-8 en fonction du protocole de transport, le DNS classique ou LLMNR.
    Dans la prochaine version, il est prévu d’inclure une implémentation DNSSEC et mDNS / DNS-SD à systemd-resolved.

  • Un nouveau module NSS nss-mymachines a été ajouté. Il résout automatiquement les noms de tous les conteneurs locaux enregistrés vers leurs adresses IP respectives.

  • Un nouvel outil client pour systemd-networkd, networkctl, a été ajouté. Il est actuellement purement passif et permet d’obtenir les configurations du réseau de udev, rtnetlink et networkd, et de les formater pour les présenter à l’utilisateur.
    Dans le futur, nous espérons l’étendre pour qu’il soit l’outil de contrôle de networkd.

  • Les unités .socket obtiennent un nouveau paramètre : DeferAcceptSec= qui contrôle l’option TCP_DEFER_ACCEPT pour les sockets TCP [N. D. T. : cette option est appelée un sockopt].
    De la même façon, la prise en charge du contrôle des paramètres keep-alive de TCP a été ajoutée (KeepAliveTimeSec=, KeepAliveIntervalSec=, KeepAliveProbes=). Enfin, la désactivation optionnelle de l’algorithme de Nagle pour TCP a été implémentée (NoDelay=).

  • logind a gagné une nouvelle session de type web, pour des projets comme Cockpit qui enregistrent des clients Web comme session PAM.

  • Les unités minuteries avec au moins un paramètre OnCalendar= sont désormais démarrées seulement après que la cible timer-sync.target a été atteinte.
    De cette façon, la limite de temps ne peut être atteinte avant que l’horloge système n’ait été corrigée, par exemple par un client NTP local.
    Ceci est particulièrement utile pour des machines embarquées sans RTC, qui ne disposent que d’une horloge système imprécise.

  • L’option --network-veth de systemd-nspawn devrait désormais fournir une adresse MAC stable pour les deux côtés de l’interface.

  • Une nouvelle option --volatile= a été ajoutée à systemd-nspawn pour exécuter des instances de conteneur avec les dossiers /etc ou /var vides.

  • Le code du client kdbus a été mis à jour pour utiliser le nouveau sous‐système memfd du noyau Linux 3.17 à la place de l’ancienne interface spécifique à kdbus.

  • Le client et le serveur DHCP de systemd-networkd connaissent désormais l’option FORCERENEW.
    De nouvelles options ont aussi été incluses pour configurer l’identifiant vendeur du client et le mode diffusion (broadcast) pour DHCP.

  • systemd n’informera plus le noyau de la zone horaire, puisque cette information est nécessairement incorrecte et hasardeuse, car le noyau n’a, par exemple, aucune connaissance de l’heure d’été. Cela signifie que les horodatages (timestamps) FAT seront toujours considérés comme en temps universel (UTC), ce qu’Android fait déjà. Enfin, lorsque l’horloge matérielle indique l’heure locale (plutôt qu’UTC), systemd ne la resynchronisera pas, puisque cela peut induire Windows en erreur lors du prochain démarrage.

  • Une nouvelle option verify a été incluse dans systemd-analyze pour valider hors ligne les fichiers unités.

  • Plusieurs paramètres ont été inclus dans systemd-network pour configurer l’amalgame d’interfaces réseau.

  • Le client DHCP de systemd-network ne demande plus la diffusion (broadcast) par défaut, puisque cela impactait négativement certains réseaux. Pour les matériels où la diffusion est requise, elle peut être réactivée en utilisant l’option RequestBroadcast=yes.

  • systemd-networkd va désormais configurer les adresses IPv4LL (si elles sont activées), même si DHCP a été configuré avec succès.

  • udev va désormais respecter les noms donnés par le noyau aux interfaces réseau, lorsque celui‐ci indique qu’ils sont prédictibles. Ce comportement peut être modifié en changeant l’option NamePolicy= dans le fichier .link correspondant.

  • Une nouvelle bibliothèque systemd-terminal a été ajoutée. Elle implémente un moteur complet d’analyse et de rendu des flux de type « terminal texte » (TTY).
    Cette bibliothèque a été pensée pour pouvoir implémenter un sous‐système de terminaux virtuels (VT) complet s’exécutant en espace utilisateur, pour remplacer l’implémentation actuelle du noyau.

  • Un nouvel outil, systemd-journal-upload permet d’envoyer les données du journal à une machine distante exécutant systemd-journal-remote.

  • journald ne transmettra plus toutes les données locales à un autre démon syslog. Ce changement a été décidé, car rsyslog (qui semble être l’implémentation la plus répandue de syslog de nos jours) n’utilise plus cette possibilité. À la place, il extrait directement les données depuis le journal.
    Puisque transmettre ces données à un serveur syslog non existant demande plus de ressources que nous le supposions, cette option a été désactivée.
    Si vous exécutez un serveur syslog qui n’est pas une version récente de rsyslog, vous devez activer cette option (ForwardToSyslog= dans le fichier journald.conf).

  • journald prend désormais en charge l’algorithme de compression LZ4 pour les gros champs du journal.
    Cette compression devrait être plus performante que XZ, la précédente option par défaut.

  • machinectl montre désormais l’adresse IP des conteneurs locaux s’il les connaît, ainsi que le nom de l’interface du conteneur.

  • Un nouvel outil systemd-escape a été ajouté. Il permet de facilement protéger les chaînes de caractères qui seront utilisées pour construire les noms d’unités.

  • Les messages sd_notify() peuvent désormais inclure un nouveau champ, ERRNO=, qui est lu et enregistré par systemd.
    Il sera affiché dans la sortie fournie par la commande systemctl status pour le service concerné.

  • Un nouveau composant systemd-firstboot permet de demander à l’utilisateur les informations de base de systemd (zone horaire, nom de la machine, mot de passe root) lors d’un premier démarrage. Il peut aussi être utilisé pour fournir ces informations à des images Linux installées dans des répertoires [N. D. T. : par exemple un chroot ou un conteneur].

  • Les exemples préinstallés de sysctl.d auront désormais l’option net.ipv4.conf.default.promote_secondaries=1, ceci afin de ne pas supprimer les adresses IP secondaires lorsque les adresses primaires l’ont été.

Les personnes suivantes ont contribué à cette version :

Ansgar Burchardt, Bastien Nocera, Colin Walters, Dan Dedrick, Daniel Buch, Daniel Korostil, Daniel Mack, Dan Williams, Dave Reisner, David Herrmann, Denis Kenzior, Eelco Dolstra, Eric Cook, Hannes Reinecke, Harald Hoyer, Hong Shick Pak, Hui Wang, Jean‐André Santoni, Jóhann B. Guðmundsson, Jon Severinsson, Karel Zak, Kay Sievers, Kevin Wells, Lennart Poettering, Lukas Nykryn, Mantas Mikulėnas, Marc‐Antoine Perennou, Martin Pitt, Michael Biebl, Michael Marineau, Michael Olbrich, Michal Schmidt, Michal Sekletar, Miguel Angel Ajo, Mike Gilbert, Olivier Brunel, Robert Schiele, Ronny Chevalier, Simon McVittie, Sjoerd Simons, Stef Walter, Steven Noonan, Susant Sahani, Tanu Kaskinen, Thomas Blume, Thomas Hindoe Paaboel Andersen, Timofey Titovets, Tobias Geerinckx‐Rice, Tomasz Torcz, Tom Gundersen, Umut Tezduyar Lindskog et Zbigniew Jędrzejewski‐Szmek.

systemd et Gentoo

La distribution Gentoo Linux fournit par défaut son propre système d’init : OpenRC. Une des forces d’OpenRC est son intégration avec le principe fondamental de Gentoo : la personnalisation. Jusqu’à cet été, j’ai vécu très heureux avec ce système. Néanmoins, Gentoo pousse la personnalisation du système jusqu’à proposer l’utilisation de systemd comme système d’init pour les utilisateurs qui le veulent (ou qui veulent utiliser toutes les possibilités de GNOME 3). Pour le plaisir de tester, j’ai basculé mon ordinateur portable sous systemd.

L’installation se fait facilement en suivant les étapes ci‐dessous :

  1. recompiler le noyau pour activer l’option OpenRC ou systemd fournie par l’équipe Gentoo, et reconstruire l’initramfs pour appeler l’exécutable systemd ;
  2. activer le profil systemd (ou activer manuellement les bons useflags — principalement USE=systemd -consolekit) ;
  3. recompiler son système (la partie la plus longue du processus) ;
  4. configurer (à la main ou en utilisant les utilitaires de systemd) ;
  5. profiter !

Une description détaillée de la procédure est disponible sur le wiki du projet Gentoo. Vous pourrez aussi trouver une rapide description des différents systèmes d’init.

Je n’ai malheureusement pas grand chose à dire de plus, car tout a fonctionné directement sans problème. Ce qui témoigne à la fois de la qualité de systemd, mais aussi et surtout de la qualité de l’intégration faite par l’équipe de développement de Gentoo. Il faut toutefois noter que systemd et OpenRC sont très différents dans leur configuration. Cependant, puisque systemd est très répandu, la documentation est abondante. L’apparition d’utilitaires comme systemd-firstboot devrait faciliter cette étape de configuration. Ce nouveau système est plus rapide, comme attendu. Cependant, je l’ai installé sur un nouveau SSD, la comparaison est donc légèrement biaisée.

Aller plus loin

  • # networkctl

    Posté par  . Évalué à 1.

    Un grand merci !!! networkctl manquait vraiment! Cet outil est vraiment sympa, il permet de trouver beaucoup plus facilement les noms d'interfaces, surtout depuis qu'ils sont étranges, ex. enp0s25 pour ma première interface Ethernet.

    D’ailleurs, est-ce que quelqu’un pourrait expliquer pourquoi ces noms étranges au lieu des anciens noms qui me paraissaient quand même plus simples à utiliser.

    • [^] # Re: networkctl

      Posté par  . Évalué à 10. Dernière modification le 31 octobre 2014 à 09:56.

      Voici une explication quand Fedora a décidé de passer à cette convention de nommage :
      Sortie de Fedora  15 « Lovelock » / Nommage déterministe des cartes réseau

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: networkctl

      Posté par  . Évalué à 10.

      Tu as l'explication de ton nom d'interface, et les explications pour le changer, sur la page Predictable Network Interface Names.

      En bref, la convention de nommage suit maintenant la convention du noyau, mais on peut soit revenir à l'ancien système, soit se créer une règle udev personnalisée.

      Personnellement, le passage à un réseau piloté par systemd a été un grand soulagement. Avant cela, quand je revenais d'hibernation sur mon portable, mon réseau filaire était parfois bloqué : impossible d'obtenir une réponse DHCP. Couper l'interface et la réactiver n'y changeait rien, idem avec le pilote noyau. J'ai fini par essayer de passer à systemd-networkd. Ça m'a fait bizarre de virer /etc/network/, /etc/init.d/network et ifup de ma Debian, mais mon portable fonctionne mieux qu'avant.

    • [^] # Re: networkctl

      Posté par  . Évalué à 2.

      J'avais lu un bout de doc RedHat la-dessus.

      Par contre pour ton cas : enp0s25. Euh, je ne vois pas la correspondance.

    • [^] # Re: networkctl

      Posté par  (Mastodon) . Évalué à 4.

      Je ne connais pas networkd, mais que fait cet outil de si extraordinaire par rapport aux interfaces réseau ?
      En quoi est-ce plus simple / puissant / mieux que 'ip link' par exemple ?

      Merci d'avance de m'éclairer, j'essaie de comprendre un peu de quoi il retourne avec systemd, qui risque de se retrouver un peu partout, et auquel je n’écharperai donc sans doute pas…

      • [^] # Re: networkctl

        Posté par  (site web personnel) . Évalué à 7. Dernière modification le 31 octobre 2014 à 17:51.

        L'intêret principal que j'y vois est l'interface unifié pour accéder aux différents protocoles. Un développeur d'application peut aller chercher toutes les informations relatives aux réseaux à un seul endroit, et n'a pas à faire 10000 tests pour être sur que 10000 utilitaires différents sont bien accessibles.

        Par exemple si on doit faire une synchronisation avec un serveur distant, on peut vouloir vérifier que le réseau est bien disponible, que le proxy est correctement configuré, que la date/heure est correcte, que le dns est fonctionnel, … Pouvoir réaliser toute ces opérations avec une seule interface est relativement importante, et semble être le moteur principale de ces développements.

        Une fois ces changements fait on pourra configurer NTP depuis NetworkManager, du point de vue utilisateur ça simplifie la vie (c'est sans doute possible dés maintenant de modifier NM pour configurer NTP, c'est juste beaucoup plus compliqué sans une interface unique). Cela risque d'imposer l'API de systemd dans beaucoup d'applications, mais c'est sans doute un mal pour un bien, l'année du desktop linux va bientôt arriver :) .

      • [^] # Re: networkctl

        Posté par  . Évalué à 8.

        En quoi est-ce plus simple / puissant / mieux que 'ip link' par exemple ?

        iproute2, ça ne gère pas le dhcp, l'adressage statique au démarrage, les DNS…

        « 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

  • # systemd + Gentoo

    Posté par  . Évalué à 3.

    J'ai également la même expérience que toi : ça marche juste. Le seul point qui semble mal intégré est le support de NFS Server. Mais il est possible de trouver les fichiers services à rajouter sur des forums.
    Après, c'est une machine perso et non un serveur donc, je n'ai pas poussé plus loin l'administration.

    • [^] # Re: systemd + Gentoo

      Posté par  (site web personnel) . Évalué à 1.

      C'est vrai, j'ai galéré un peu avec NFS dernièrement. Le problème avec NFS vient du fait qu'ils existent plusieurs versions du serveur NFS et que chaque version à des dépendances un peu différentes…
      Il semblerait que les dépendances systemd de Gentoo soit configuré pour être utiliser avec la version 3, mais que d'autres distribution, (par ex. Centos 7) utilise par défaut la version 4 (qui si elle est compilé dans Gentoo sera utilisé mais ne fonctionnera pas si les dépendances systemd ne sont pas correctement initialisées). Forcer l'utilisation de la version 3 met tout le monde d'accord (c'est la solution que j'ai adoptée)…
      Le problème est un peu partagé entre systemd et le joyeux bordel qu'est NFS. Mais de mémoire, faire fonctionner NFSv4 a toujours été plus compliqué, même quand tout était mieux et plus simple…

      Sinon, je tenais à remercier les personnes qui ont fini la dépêche ! Pris dans l'engrenage infernal d'autres projets, j'avais un peu oublié qu'elle était dans les tuyaux et je ne jetais un oeil à linuxfr qu'en diagonal. donc : Merci :)

      • [^] # Re: systemd + Gentoo

        Posté par  (site web personnel) . Évalué à 2.

        Le problème est un peu partagé entre systemd et le joyeux bordel qu'est NFS. Mais de mémoire, faire fonctionner NFSv4 a toujours été plus compliqué, même quand tout était mieux et plus simple…

        J'ai remarqué que les partages NFS entre deux Debian Wheezy se font via NFSv4 par défaut, donc tu n'as rien à faire, chez moi, cela a été complètement transparent… Il me semble que la version 3 limite le nombre de groupe d'une personne à 16 ce qui est un problème.

        • [^] # Re: systemd + Gentoo

          Posté par  (site web personnel) . Évalué à 2.

          Mon expérience avec NFS et debian date de quelques années et il est bon de voir que les choses ce sont améliorées. Mais les choses en générales se compliquent lorsque l'on commence à mixer les distributions (surtout si on choisit stabilité (obsolescence) pour le serveur et cutting-edge pour les clients). Mais il y certainement du travail à faire du côté de Gentoo (ne serait-ce que sur la doc).

          • [^] # Re: systemd + Gentoo

            Posté par  (site web personnel) . Évalué à 3.

            Comme j'utilise NFS en mode simple (sans la sécurité que peut apporter la version 4), je n'active les partages qu'entre des machines dont j'ai le contrôle, donc 99% sont sous Debian. Ceci dis, j'ai jamais eu plus de soucis que cela avec RH ou Suse. Le principal soucis est que tout est en mode noyau donc quand cela pars en sucette, tu reboot ! Heureusement, cela n'arrive pas si souvent que cela. Il faut aussi oublier LXC et les containers car NFS, en mode noyau, n'est pas vraiment compatible avec cela… A par cela, tout marche relativement bien tout seul.

  • # Est-ce vraiment un programme de "production" ?

    Posté par  . Évalué à -1. Dernière modification le 01 novembre 2014 à 01:45.

    Dites les gars, ça a l'air marrant votre engin :

    • Une page de bug-report avec plus d'entrées qu'un forum Usenet.

    • Une nouvelle version tous les mois.

    Tant de changement en si peu de temps, d'ordinaire ce n'est pas l'usage dans le monde de la "Prod".

    (sauf les irréductibles de *BSD, bien sûr)

    Ho oui, "moinssé" moi :-)

    • [^] # Re: Est-ce vraiment un programme de "production" ?

      Posté par  . Évalué à 10.

      Une liste de bug 2,5 fois plus grande que ce qu'on trouve sur usenet, une version tous les deux mois : c'est vraiment pas prêt pour la prod.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Est-ce vraiment un programme de "production" ?

      Posté par  . Évalué à 8.

      Ca tombe bien que tu demandes. J'ai une debian, et lors d'une migration j'ai eu un systemd qui c'est installé.
      Lors du premier redémarrage avec, je n'ai pas eu trop de problème (sauf un problème d'intégration et de migration : certains services ne prenaient pas en compte les valeur définies dans /etc/default et forcément ça ne marchait pas … C'était pourtant les valeurs par défaut de la distrib (valeurs pas modifiées donc ) . Ca c'est un pb de debian et pas forcément de systemd).

      Bref je vivotais avec systemd en essayant d'avoir un avis sans préjugé.
      J'ai vu des trucs très sympa, comme le fait de pouvoir rajouter des respawn sur n'importe quel service, de changer les limites (nofile, …), et le fait de pouvoir changer un script d'init (enfin un "unit file") juste en rajoutant un fichier et en mettant que les valeurs "kivonbien" (donc ne pas modifier le script initial).
      la liste de systemctl avec indication des failed itou est aussi sympa .

      Bon par contre la documentation est vraiment pas clair et on perd énormément de temps à chercher ce qu'il nous faut

      Bref jusqu'à hier, ce n'était pas parfait mais ça marchait plutôt bien.
      Et hier, je fais une maj normal, je ne change rien de critique dans mes paquets ni rien (style maj de blender etc…) et je redémarre.

      Deja au démarrage il me sort "start a job for /dev/… (25 s / 1 m 30s)" …
      (et oui ça a bien duré 1 m 30 sec. Aucune explication de ce qu'est ce truc qui ressemble plus à un timer qu'à autre chose).
      il continue après à afficher des OK , et quelques failed (qui sont sans importance vu que c'est des programmes acessoires).
      Après une bonne quinzaine de "ok" , il me sort "oups j'ai rencontré un problème. Je passe en Emergency, tape journalctl -xn , puis systemctl reboot pour rebooter, ou systemctl default pour continuer)
      Bon il faut donner le mot de passe root pour corriger ok allons y.
      tapons les commandes qu'il nous a fournis.
      ET là on arrive dans le niveau 0 de l'utilité.
      J'ai les 10 dernières lignes … qui concernent des erreurs udev sur le fichier 85_logi_mouse.conf et c'est tout.
      (une bonne 15-aine de service minimum sont passé après le démarrage de udev)
      bon on recherche un peu avec un journalctl --help, journalctl -x --no-tail . On a tous les logs de démarrage …
      Mais toujours aucune indication de pourquoi il plante.

      Bon ressortons du mode emergency et faisons un ctrl+d (essayer de continuer sans passer en root)
      … il freeze sur le exit de la console d'emergency.
      Reboot avec les sysmagickey, re attente de 1 m 30, et cette fois ci ctrl+d avant de se connecter.
      Il freeze pendant 1 ou 2 min, puis il me raffiche le même message comme quoi il faut que je me logge. Pas de nouveau message qui pourrait m'aider à cibler ce qui ne vas pas.

      Reloggons nous, constatons a quel point la gestion du terminal de cette console est pitoyable (backspace supprime le caractère en l'affichant à nouveau, on ne parle pas de complétion ou autre…)
      essayons de lancer un zsh, ah ça plante. Il doit pas avoir monté les partoches. C'est balot …
      mount -a, ca bloque pendant 30 seconde ou une minute, en mettant une floppée de warning,mais ca marche au final.
      Quelques tests pour essayer de trouver, et puis je sais plus trop ce que je fais , à nouveau freeze complet de l'interface. sysmagickey à la rescousse.

      Bon essayons avec un init=/bin/sh.
      AH déjà le terminal marche mieux.mount -o remount,rw /, /Etc/init.d/udev … ouip tout marche \o/
      bon le lvm ne marche plus, obligé de faire un vgchange -a y, puis de monter directement les dm-? , car udev n'arrive pas à lister les lv (pourtant lvs les affiche bien).
      Après quelques tests, je veux accéder au réseau : ifup eth0, ca marche
      /etc/init.d/bind9 … "tentative de démarrage du service avec systemctl… Echec, impossible de trouver une session dbus".

      Ah c'est sur que si il n'y a pas de fallback à systemctl on est dans la merde.

      Après encore deux trois reboot et tatonnement j'ai fait un test dans lequel j'ai réussi à faire marcher le tout

      console emergency -> login as root -> mount -a -> init 5
      et ca passe (surtout pas systemctl default après le mount -a, ca freeze irrémédiablement)

      Et je ne sais toujours pas pourquoi il plante.

      Systemctl redémarre plus rapidement ?
      Non -> un timer d'1m30s dans un boot, c'est plus long que tout mon précédent boot, avec une floppée de service
      Non -> devoir passer 1h30 à 2h00 pour avoir le droit de démarrer sa machine, et sans indication claire de quel étape plante, c'est affligeant pour un système censé aider l'admin sys.

      • [^] # Re: Est-ce vraiment un programme de "production" ?

        Posté par  . Évalué à 3.

        Pour les erreurs au démarrage, c'est simple :

        Erreur au lancement
        $ systemctl --failed

        UNIT LOAD ACTIVE SUB JOB DESCRIPTION
        dhcpcd@eth0.service loaded failed failed dhcpcd on eth0

        LOAD = Reflects whether the unit definition was properly loaded.
        ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
        SUB = The low-level unit activation state, values depend on unit type.
        JOB = Pending job for the unit.

        1 units listed. Pass --all to see inactive units, too.

        systemctl status dhcpcd@eth0.service

        dhcpcd@eth0.service - dhcpcd on eth0
        Loaded: loaded (/usr/lib/systemd/system/dhcpcd@.service; disabled)
        Active: failed (Result: exit-code) since Tue, 31 Jul 2012 15:09:03 +0200; 2min 58s ago
        Process: 1251 ExecStart=/sbin/dhcpcd -A -q -w %I (code=exited, status=1/FAILURE)
        CGroup: name=systemd:/system/dhcpcd@.service/eth0

        Jul 31 15:09:03 archtest dhcpcd[1251]: dhcpcd already running on pid 311 (/run/dhcpcd-eth0.pid)

        Un autre dhcpcd est en cours :
        $ ps h -C dhcpcd -o cgroup

        3:cpuacct,cpu:/system/wicd.service,1:name=systemd:/system/wicd.service

        C'était à des fins de tests, wicd.service était lancé.

        source : ici

        Quant à la doc en ligne ou les manuels de systemd et ses outils, je n'ai absolument rien à leur reprocher.

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: Est-ce vraiment un programme de "production" ?

          Posté par  . Évalué à 5.

          ca c'est la théorie.
          Dans la pratique, systemctl |grep failed sort la même chose … et n'explique pas pourquoi
          1°) aucun des unit "failed" sont critique dans mon cas (kernelloops service, nut-driver, rng tools, tftp, et systemload-modules *)
          2°) pourquoi en faisant manuellement mount -a , puis init 5 (et pas systemctl --default) ca marche
          3°) pourquoi il a une tendance impressionnante à freezer en interactif.

          • : mon noyau est custom, et les modules ne sont pas nécessaire au démarrage. Tout est dispo , que ce soit lvm, le réseau, ou les drivers X , en dur et pas en module.

          Enfin que la documentation te convienne, libre à toi. Personellement à chaque fois que j'ai du chercher comment faire un truc, j'ai trouvé des informations plutot dans les forums que dans la doc …
          Ah oui ils indiquent bien qu'il y a tel ou tel variable. Par contre trouver comment la positionner (non set-env ne marche pas) ou encore, qu'après avoir modifié un unit il faut systématiquement faire un reload de systemd

          • [^] # Re: Est-ce vraiment un programme de "production" ?

            Posté par  . Évalué à 3. Dernière modification le 01 novembre 2014 à 22:25.

            Dans la pratique, systemctl |grep failed sort la même chose … et n'explique pas pourquoi

            Dans l'exemple que j'ai cité (et le cas que j'ai eu chez moi qui découlait du fait que mon fstab était mal fichu) c'est pourtant le cas…

            Quoi qu'il en soit, je doute que tu ne trouves toujours pas dans le journal en te référant à ce commentaire

            1°) aucun des unit "failed" sont critique dans mon cas (kernelloops service, nut-driver, rng tools, tftp, et systemload-modules *)

            Ça m'étonnerait vu que ça a planté. Dans tous les cas, j'aurais tendance à soupconner une erreur utilisateur. Après tout, tu as bien dit qu'aucune des mises à jours ne concernait le système et que le boot s'était arrêté sur la lecture d'un fichier de conf' perso… ;-)

            2°) pourquoi en faisant manuellement mount -a , puis init 5 (et pas systemctl --default) ca marche

            Je sais pas ce que tu fais à mélanger des runlevels avec systemd, mais je crois que ton setup est juste dégeulasse.
            Chez moi init 1/2/3/4/5-tout-ce-que-tu-veux ça ne veut rien dire pour systemd.

            3°) pourquoi il a une tendance impressionnante à freezer en interactif.

            installation dégeulasse. Il freeze pas chez moi.

            Enfin que la documentation te convienne, libre à toi. Personellement à chaque fois que j'ai du chercher comment faire un truc, j'ai trouvé des informations plutot dans les forums que dans la doc …

            Non, décidément, y'a franchement pas à se plaindre entre les manuels en local et la documentation en ligne.
            En plus des autres wiki comme celui d'Archlinux…

            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: Est-ce vraiment un programme de "production" ?

        Posté par  . Évalué à 4.

        Tu peux ajouter des paramètres à la ligne de ce commande du noyau pour avoir plus d'information de debug https://wiki.debian.org/systemd#Debugging

        (Pour moi, ça devrait être fournit par la distribution avec l'entrée rescue de grub).

        « 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: Est-ce vraiment un programme de "production" ?

        Posté par  . Évalué à 10.

        au démarrage il me sort "start a job for /dev/… (25 s / 1 m 30s)" …
        (et oui ça a bien duré 1 m 30 sec. Aucune explication de ce qu'est ce truc qui ressemble plus à un timer qu'à autre chose).

        Effectivement, c'est un timer. Une unité ne démarre pas, et lorsque la durée TimeoutStartSec est écoulée, systemd considère cette unité comme défaillante (voir également DefaultTimeoutStartSec). Ces durées sont, par défaut, de 90 secondes, cela correspond à ton cas.

        Pour diagnostiquer ce qui empêche ta machine de démarrer, tu peux utiliser journalctl avec les options suivantes :

        Une fois que tu as identifié l'unité défaillante, tu peux filtrer les logs pour n'avoir que ceux de cette unité, avec journalctl -u machin.unité

        Ces différentes options de journalctl sont cumulables.

    • [^] # Re: Est-ce vraiment un programme de "production" ?

      Posté par  . Évalué à 3. Dernière modification le 01 novembre 2014 à 10:03.

      Dit mon gars, ça a pas l'air drôle d'être de mauvaise foi.

      Une page de bug-report avec plus d'entrées qu'un forum Usenet.

      Ça ne veut rien dire. Un "bug report" ça peut être :
      - un bug non critique
      - une demande de fonctionnalité
      - une incompréhension (un bug qui va finir sur un WONTFIX, quoi)
      - etc …

      Et puis bon, montre moi un logiciel sans aucun bug… Si SysV était parfait, on aurait pas fait Upstart, OpenRC, systemd, etc…

      Une nouvelle version tous les mois.

      Tu préfères avoir très peu de contributeurs, et une version à la traîne tous les deux ans ?
      Super…

      Tant de changement en si peu de temps, d'ordinaire ce n'est pas l'usage dans le monde de la "Prod".

      Je vois pas le rapport. D'autant qu'on est pas obligé, quand on est un minimum intelligent avec sa "Prod", de déployer chaque nouvelle version sans attendre…

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

    • [^] # Re: Est-ce vraiment un programme de "production" ?

      Posté par  (site web personnel) . Évalué à 4.

      Une page de bug-report avec plus d'entrées qu'un forum Usenet.

      Il y a 2 type de logiciels : ceux avec une page de bug-report avec plus d'entrées qu'un forum Usenet, et ceux non utilisés. tu n'aimes simplement pas les trucs qui qont assez utiles pour êtres utilisés, tu préfères les logiciels peu utiles.

      Une nouvelle version tous les mois.

      Bon, ça, je n'ai pas trouvé d'autres idées que les autres montrer la stupidité de l'argumentation.
      Ah peut-être : release early, release often, c'est pas un truc du libre? Tu n'aimes pas le libre?

    • [^] # Re: Est-ce vraiment un programme de "production" ?

      Posté par  (site web personnel) . Évalué à 7.

      Tant de changement en si peu de temps, d'ordinaire ce n'est pas
      l'usage dans le monde de la "Prod".

      Tu sais, y a pourtant des boites qui font des mises en prod tout les jours. Genre facebook, etc. Je t'invite à lire "the phoenix project", malgré le fait que l'histoire soit pas terrible pour un roman et un chouia ultra cliché, mais ça montre l'avantage de faire des mises en prod réguliére, car ça accelere la boucle de retour entre la partie métier d'une boite ( et donc, les retours utilisateurs ) et les cdoeurs, ce qui permet d'augmenter la satisfaction des gens ( genre, pas attendre 6 mois qu ele service info fasse un changement ).

      Ensuite, j'imagine que tout les cas d'utilisation ne s'y retrouvent pas ( même si je pense qu'une grande partie du conservatisme des services financiers pour ne coter qu'eux doit venir du fait que les trucs d'Oracle sont vieux et vieillissants ).

      Sinon, si tu veux de la prod qui ne bouge pas, Centos 7 est supporté pour longtemps, RHEL aussi, et SLES également. Ce genre de distributions t'isole des releases et de la cadence du libre.

      • [^] # Re: Est-ce vraiment un programme de "production" ?

        Posté par  . Évalué à 7.

        même si je pense qu'une grande partie du conservatisme des services financiers pour ne coter qu'eux doit venir du fait que les trucs d'Oracle sont vieux et vieillissants

        Ah, tu parle des trucs de jeune, ceux pour lesquel le Cobol a une interface Oracle, tous n'y sont pas encore.

        « 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

  • # Lien précédent

    Posté par  . Évalué à 3. Dernière modification le 02 novembre 2014 à 13:43.

    Comme j'ai mis du temps à retrouver l'article précédent (que je n'ai pas encore lu), je le remets pour tout le monde :
    https://linuxfr.org/news/systemd-versions-212-a-215

Suivre le flux des commentaires

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