Aller à la recherche

Des Logiciels Libres

Pour parler de Logiciels Libres en milieu professionnel... ou pas!

mardi, février 5 2013 00:37

Mais où est passé systemd-analyze?

Si vous venez de faire une installation toute fraîche de Fedora 18 vous serez peut être étonné que la commande systemd-analyze n'est plus disponible de base. Cette commande très utile est dans le paquet "systemd-analyze", qu'il suffit d'installer:

yum install systemd-analyze

Et voilà! Utile pour diagnostiquer un démarrage lent:

$ systemd-analyze blame
  2055ms postfix.service
   601ms systemd-udev-settle.service
   530ms firewalld.service
   476ms fedora-storage-init.service
   451ms iscsid.service
   335ms bluetooth.service
   229ms abrt-ccpp.service
   222ms systemd-binfmt.service
   204ms NetworkManager.service
   199ms fedora-storage-init-late.service
   195ms systemd-logind.service
   185ms avahi-daemon.service
   169ms ntpd.service
   162ms cpupower.service
   159ms acpid.service
   158ms fedora-loadmodules.service
   127ms systemd-udev-trigger.service
   105ms sshd.service
   103ms systemd-readahead-collect.service
   101ms abrt-vmcore.service
    98ms ksmtuned.service
    93ms gdm.service
    93ms lvm2-monitor.service
    92ms sys-kernel-debug.mount
    90ms systemd-readahead-replay.service
    85ms ksm.service
    80ms dev-mqueue.mount
    79ms udisks2.service
    78ms proc-sys-fs-binfmt_misc.mount
    68ms dev-hugepages.mount
    67ms systemd-vconsole-setup.service
    66ms systemd-remount-fs.service
    66ms systemd-tmpfiles-setup.service
    65ms home.mount
    62ms rpcbind.service
    60ms fedora-readonly.service
    59ms bacula-fd.service
    53ms colord.service
    52ms iscsi.service
    51ms tmp.mount
    51ms systemd-sysctl.service
    48ms polkit.service
    47ms systemd-modules-load.service
    45ms boot.mount
    45ms auditd.service
    42ms sys-kernel-config.mount
    29ms wpa_supplicant.service
    27ms accounts-daemon.service
    27ms systemd-udevd.service
    23ms upower.service
    12ms rtkit-daemon.service
     9ms systemd-user-sessions.service

Pas mal cette Fedora 18, assez propre sans rien faire (et encore j'ai perdu 2 secondes au boot en installant postfix). La transition vers systemd est de plus en plus complète, vu ce qu'il reste dans init.d:

$ ls /etc/init.d/
ebtables  functions  iscsi  iscsid  libvirt-guests  netcf-transaction  netconsole  network  README

A suivre!

lundi, février 4 2013 19:44

Automount via systemd

Quand il est nécessaire d'accèder à des systèmes de fichiers particuliers, à travers le réseau (NFS, CIFS, etc) ou sur une ressource pas toujours disponible (disque externe USB), voire même pour soulager les requêtes sur ce montage, il est utile de passer par la fonctionnalité "automount". Comme son nom l'indique, cela permet de monter automatiquement un point de montage, dès la première requête d'accès sur ce dernier. L'inverse est aussi de mise, démonter le point de montage quand celui-ci n'a pas été accédé depuis un certain temps (timeout).

Avant il fallait passer par autofs/automount, et configurer un ou plusieurs fichiers de configuration pour indiquer les points de montage à gérer. Rien de très complexe ceci dit. Mais aujourd'hui, le fameux remplaçant de SystemVinit, systemd, a de nombreux avantages dont celui de prendre en charge nativement les points de montage, particulièrement pratique pour remplacer autofs/automount.

Il y a deux possibilités pour configurer un point de montage automatique avec systemd:

  • via les fichiers unit de systemd, avec la création d'un fichier .automount et son associé en .mount
  • via directement le fichier /etc/fstab

Comme ici, le but est de faire plus simple qu'à l'époque de autofs, nous allons juste voir la méthode via fstab. Attention c'est simple, il suffit d'ajouter une ligne classique du montage souhaité, et dans les options d'ajouter la mention x-systemd.automount. Et voilà le tour est joué.

Exemple avec un montage nfs4:

srvnfs:/nfs/exports/home /mnt/nfs/home nfs4 x-systemd.automount 0 0

Exemple avec un disque externe usb (ex /dev/sdb1):

UUID=a2969b8d-c90a-432e-8198-f697c23f8c96 /mnt/externe		  ext4	  noauto,x-systemd.automount 0 0

(blkid /dev/sdb1 pour avoir l'UUID).

Au prochain reboot, au moindre accès dans le point de montage indiqué par x-systemd.automount, ce dernier sera automatiquement monté. C'est magique!

vendredi, octobre 19 2012 19:51

Configurer sysctl avec systemd

Sur la prochaine Fedora 18, l'ancestral fichier /etc/sysctl.conf n'existe plus. Il faut maintenant déposer les modifications souhaitées dans un fichier .conf dans le répertoire /etc/sysctl.d.

Ce qui est dommage pour l'instant, c'est que la commande sysctl -p, que nous avions l'habitude de lancer pour prendre en compte les nouvelles modification, n'a pas connaissance de tout ceci. Elle finit donc en erreur. Ceci est dû au fait que les fichiers présents dans /etc/sysctl.d sont en réalité pris en charge par le service systemd-sysctl. Donc pour activer tout changement:

systemctl restart systemd-sysctl.service

Exemple concret pour l'activation des Magic Sysrq Keys:

echo "kernel.sysrq = 1" > /etc/sysctl.d/magic.conf
systemctl restart systemd-sysctl.service

Pour vérifier:

sysctl kernel.sysrq

Que de surprises avec cette Fedora 18!

vendredi, avril 29 2011 10:45

Pourquoi systemd?

Voici une traduction rapide de la page: why systemd?. Article très complet qui liste les avantages de systemd par rapport à ces "concurrents" directs. Très intéressant.

Lire la suite...

mardi, avril 19 2011 20:42

Le nouveau systemd

Le remplacement de l'ancestrale sysVinit pour la gestion du démarrage de la machine et de ses services est en soit une petite révolution dans le monde Linux. On lui reprochait de ne pas être assez modulaire et dynamique pour les usages qu'on fait maintenant de nos ordinateurs. Maintenant, il faut une gestion qui se base sur de l’évènementiel plutôt que sur du séquentiel, tout en gérant de l'interdépendance. C'est vrai qu'avec SystemVinit qui date des années 90, on en était loin. Il y eu plusieurs candidats (par exemple Upstart) car le sujet n'est pas nouveau et la tâche n'est pas des plus simple. Mais depuis la Fedora 14, la révolution est en marche et le choix s'est arrêté sur systemd. Celui-ci sera pleinement intégré à la future Fedora 15.

Systemd vient avec la commande systemctl, mais pour éviter d'impacter de manière trop violente nos bonnes vieilles habitudes, les commandes habituelles de gestion de service continueront de fonctionner comme avant. Ainsi, les commandes service et chkconfig peuvent toujours être utilisées sous systemd. Il est de plus compatible avec SysV et les scripts d'init LSB. Ainsi les scripts d'init habituels en shell vont pouvoir cohabiter (ceux dans /etc/init.d) avec systemd, les autres sont remplacés dans systemd par des fichiers descriptifs .service (présents dans /lib/systemd/system).

Voici par exemple, le fichier descriptif ntpd.service, tout à fait compréhensible (heureusement qu'ils ont pas choisi du XML):

[Unit]
Description=Network Time Service
After=syslog.target ntpdate.service

[Service]
EnvironmentFile=/etc/sysconfig/ntpd
ExecStart=/usr/sbin/ntpd -n -u ntp:ntp $OPTIONS

[Install]
WantedBy=multi-user.target

Les gros avantages de systemd sont sa capacité de parallélisation à outrance, la gestion des sockets (port d'écoute) et l'utilisation de DBus pour l'activation des services, ainsi que l'usage des cgroups. Il supporte aussi des options avancées pour la sécurisation des services avec la possibilité d'isolation des processus (chroot ou namespace sur le système de fichiers).

Systemd est découpé en unités (units), disposant chacune d'un nom et d'un type. Par exemple le fichier avahi.service est l'unité avahi et est de type service. Voici les principaux types:

  • service, pour gérer les démons.
  • socket, pour définir un socket. Par exemple l'unité nscd.socket si elle reçoit une demande de connexion pourra lancer l'unité nscd.service.
  • device, udev permettra d'indiquer à systemd qu'un périphérique peut être utilisé comme unité.
  • mount, cette unité permet à systemd de surveiller un point de montage.
  • automount, est associé à une unité mount qui sera activée quand on accédera au répertoire de l'unité automount.
  • target, permet de grouper plusieurs unités. Par exemple multi-user.target correspondera à peu près au demarrage des services du runlevel 5 avec SysV.
  • snapshot, permet de grouper l'état actuel des unités actives, afin de sauvegarder l'état du système pour pouvoir ensuite y revenir.

Il est donc évident que tout ceci est une nouvelle approche dans la gestion du système. Bien sûr les unités peuvent être interdépendantes ou indiquer d'éventuels conflits. Vu les différents types à disposition cela va permettre beaucoup de souplesse. Il sera par exemple possible de déclencher le montage d'un périphérique dès que celui-ci devient disponible, montage qui entrainera lui aussi d'autres dépendances, comme le démarrage d'un service... Que du bon en perspective.

Pour l'utilisateur final, l'objectif est de proposer un temps de boot bien plus rapide, dû principalement au fait que les services seront lancés en parallèle mais aussi qu'ils seront activés que s'ils sont nécessaires. D'autres tâches de gestion du système pourront être automatisées, déclenchées par exemple avec l'apparition ou la disparition d'un périphérique. De quoi disposer d'un système complètement dynamique.

Il ne reste plus qu'à attendre la sortie de la Fedora 15, prévue pour le 24 mai 2011.