Categories
Computer Technology

systemd

Voilà, comme un bon nombre de Linuxien(ne) j’utilise dorénavant systemd. Je n’ai pas vraiment un avis tranché sur ce système ni de critiques aussi virulentes qu’il est possible de trouver un peu partout sur le Web. Pour moi systemd, ça signifie d’abord que je vais devoir maîtriser une nouvelle technologie et un tas de nouvelles commandes. Ce qui m’enchante. Et puis, je trouve qu’il est parfois bien de mettre un peu de côté d’anciennes technologies. Et même si cela donne plus de travail aux administrateurs systèmes/réseaux (ceci pour ceux qui pensent encore que des binaires sont nécessaires pour configurer systemd).
Pour le moment, il faut surtout que j’identifie mieux les limites fonctionnelles de systemd. Car il faut bien le dire, systemd peut gérer un tas de choses: services, multi-seat, configuration réseau, pare-feu, etc.

systemd a amélioré le temps de démarrage de ma station fixe de travail sous Kubuntu 15.04 (environ 46 secondes, kernel et userspace) et de mon ordinateur portable sous Debian 8.0. Ce n’est cependant pas tant la vitesse qui m’intéresse, mais surtout le bon fonctionnement et les possibilités d’analyses des logs.

Concernant le fonctionnement, déjà mon démarrage est «plus propre» qu’avant. Tous les services se lancent correctement, l’affichage au démarrage n’est pas trop verbeux et est clair (homogène). Je n’ai en réalité rien de spécial à dire sur ce point (j’ai surtout gagné du temps lors du montage du NAS, qui avant me posait quelques problèmes de manière assez aléatoire).

Du côté des moyens d’analyse des logs, la commande systemd-analyze est bien pratique. Voici quelques exemples.

$ systemd-analyze dot --user --order | dot -Tsvg > systemd-dependency-graph-user.svg

Dependency graph (userspace)
Systemd dependency graph (userspace)

$ systemd-analyze dot --order | dot -Tsvg > systemd-dependency-graph-system.svg

Dependency graph (system)
Dependency graph (system)

$ systemd-analyze plot > system-services.svg

System services
System services

Le graphique ci-dessus est un peu plus parlant. Il existe aussi la commande systemd-analyze blame qui liste les services ordonnés par temps de démarrage. Ce qui peut aider à voir quel service ralenti le démarrage du système. Il faut cependant faire attention car blame ne montre pas les liens: parfois un service prend plus de temps parce qu’il attend le lancement d’un autre service.

$ systemd-analyze dot 'tor.*' | dot -Tsvg > tor.svg

Dépendances du service Tor
Dépendances du service Tor

systemctl list-units est une autre commande très pratique permettant de vérifier l’état des services après le démarrage.

Légende des graphiques:

  • black: Requires
  • dark blue: Requisite
  • dark grey: Wants
  • red: Conflicts
  • green: After
    • Finalement cette migration vers systemd est une réussite et je suis plutôt content, pour le moment. Il va tout de même falloir que je bidouille un peu plus pour me faire un avis plus précis.

Categories
Technology

Test de Debian GNU/Hurd

hurd

Hurd me semble plutôt stable par rapport à ce que l’on en dit généralement.

P.S.: Ce billet a été envoyé depuis Blogillo.

Categories
Linux

Upstart et systemd

Une autre manière de voir les différences entre Upstart et systemd.

Categories
Technology

systemd, init et upstart

Si en ce moment tu es un peu perdu entre systemd, init et upstart (plus udev, D-Bus, DCOP, etc.), je pense que ce billet sera d’une bonne aide.

Pour avoir de bonnes informations à propos de systemd:

Categories
Computer

À propos du multiprocessing

osm-parsing

J’aimerai bien pouvoir vraiment profiter de 8 coeurs pour le développement. Au lieu de laisser tourner un script plus de 4 heures sur 1 coeur. De temps en temps, il change de coeur cependant. Certainement pour qu’ils puissent se reposer.