Cheatsheet Systemd

Notes en vrac pour gérer Systemd et ainsi être capable de désactiver tous les services inutiles qui se lancent au démarrage (Windows's style)...

Ce tuto s'inscrit dans la continuité de ceux-ci :

• Mesurer les performances du démarrage de sa machine.
• Optimiser le boot et réduire sa durée de 40%.

Sommaire

Gestion sous KDE avec kde-config-systemd

Il s'agit d'un module dédié à la gestion clic/bouton de Systemd, s'intégrant dans les paramètres de KDE.

Le paquet vient du projet: kcmsystemd 1.2.1 qui lui est en version.

Depuis le ftp de Debian :

wget http://ftp.debian.org/debian/pool/main/k/kde-config-systemd/kde-config-systemd_0.7.0-1_amd64.deb
sudo dpkg-i kde-config-systemd/kde-config-systemd_0.7.0-1_amd64.deb

Aller dans configuration du système, un bouton a été ajouté avec le nom "systemd".

Interroger le journal système en temps réel

journalctl -f

Démarrer/Arrêter un service

systemctl start <service>
systemctl stop <service>

Envoyer un signal d'arrêt (SIGTERM) à tous les processus d'un service

Plus élégant qu'un killall qui tue en fonction d'une chaine de caractère.

systemctl kill NetworkManager.service

Activer/Supprimer un service au démarrage

systemctl enable <service>
systemctl disable <service>

Commande que le système exécute pour systemctl enable sshd.service:

ln -s '/usr/lib/systemd/system/sshd.service' '/etc/systemd/system/multi-user.target.wants/sshd.service'

Empêcher/Autoriser le chargement même manuel d'un service

systemctl mask <service>
systemctl unmask <service>

Lister tous les services

systemctl

Lister tous les services/cibles (targets) actifs

Disponibles :

systemctl list-unit-files
systemctl list-unit-files --type=target

Actifs :

systemctl list-units --type=service
systemctl list-units --type=target

Lister les services en échec

systemctl --state=failed

Statut et détails d'un service

systemctl is-active <service>
systemctl status <service>

ou pour tous les services:

journalctl -xe

Lister les dépendances d'une unité

systemctl list-dependencies sshd.service

--reverse : unités qui dépendent --before, --after : unités qui démarrent avant et après

Détails d'une unité

systemctl show sshd.service

Les sorties des scripts

The systemctl commands will not write it to standard output. systemd writes the output of init scripts and all status messages generated by systemd to something called journal, a log database and syslog replacement. You can conveniently get the last relevant lines of output from the status command.

Attention ! Réactiver l'écriture des logs est couteux en temps (de démararge) et en accès disque !

Activer un journal persistant

mkdir /var/log/journal
chgrp systemd-journal /var/log/journal
chmod g+rwx /var/log/journal

Rechercher les entrées pour un service dans le journal

journalctl -u <service>

Création de service

Les unit peuvent être de plusieurs types: service, socket, device. Elles sont placées dans /lib/systemd/system et /etc/systemd/system mais c'est ce dernier qui a la priorité maximale. Pour écraser une unit système, il suffit de copier le fichier existant de /lib/systemd/system vers /etc/systemd/system.

Pour écraser seulement quelques directives, il peut suffire de créer un dossier fichier .conf dans un dossier basé sur le nom de l'unit:

exemple : /etc/systemd/system/unit_name.service.d

Un autre type d'unit: les templates

Example of such unit: service_name@.service Instanciation of unit: service_name@instance1.service An instance file is usually created as a symbolic link to the template file, with the link name including the instance identifier. In template its possible to use variables:

%i - instance name, e.g. instance1
%I - same as above but with reversed escaping

Utilisation:

systemctl start openvpn@tun1.service - enable service instance (e.g. here openvpn tun1 instance)

Sections:

[Unit]      contient de l'information générique sur le service.

    PS: Targets are similar to runlevels, but for reasons of flexibility
    the systemd developers have built in an extra layer of abstraction.


    Requires=   Units on which this unit depends.
                They start in parallel with current unit by default.
                If start of them impossible (not found or failed) current unit will also fail.
    Wants=      like Requires but less strict - will simply ignore failed units.
    BindsTo=    like Requires but causes current unit stop if binded unit was terminated
    Before=     units which will wait this one
    After=      units which should be started before this one
    Conflicts=  units that can't run when this run
    Condition...= conditions on which unit will be run, if not met it will be skipped
    Assert...= as conndition but will cause failure instead of skipping

[Service]   concerne l'information sur le service en lui-même.

    Type=
        simple      By default if Type= not set but ExecStart= is set
        forking     Type declares this service as forking, meaning that the service
                    follows the traditional unix pattern of a daemon forking its process.
                    (ie: If the main process can fork child and exit immediately)
                    => Use PIDFile to set the file where the PID of the child that should be monitored is.

        oneshot     Default when both Type= and ExecStart= not set.
                    For process will short lived and systemd should wait.
                    To leave service in active state set even after process finished use RemainAfterExit=

    PIDFile=    The process id of the service.
                Recommended to be used if the daemon forks because
                then “systemd can identify the main process of the daemon”.



    ExecStart=  full path and args to command. To ignore non-zero exit codes use - add first character in command
    ExecStartPre= same as previous but will be run before command
    ExecStartPost= will be run after main process started
    ExecReload= command that should used for reload if needed
    ExecStop= custom stop command. If not set process will be killed
    ExecStopPost= command to run after stop.
        Values: always, on-success, on-failure, on-abnormal, on-abort, or on-watchdog.
    Restart= circumstances under which systemd will attempt to restart
    RestartSec= specifies wait timeout before restart using previous setting
    TimeoutSec= - how many systemd will wait for starting/stopping.
        If was not started will be marking failed, if not stopped will be forcefully killed.
        Separate timeout can be set as well: TimeoutStartSec= and TimeoutStopSec=


[Install]   concerne le comportement à avoir lorsque le service est activé/désactivé

    WantedBy=   Similar to Wants= in [Unit] section but related to called instead of caller:
                If current unit has WantedBy=multi-user.target, the directory multi-user.target.wants
                will be created in /etc/systemd/system (if not already available) and symlink
                to current unit will be created in that dir when unit is enabled.

    RequiredBy= Similar to previous but will cause a fail if conditions not met.
                Create directory which ends with .requires

    Alias=      Allows the unit to be enabled under another name as well
    Also=       Supporting units that should always be available when this unit is active

Création

• Créer le fichier /etc/systemd/system/mon-service.service et attribuer les droits :

chmod a+x /etc/systemd/system/mon-service.service

[Unit]
    Description=Short description
    # "Requires" prevents service start if the requirement isn't met,
    # but without "After", dependencies will be launch in parallel.
    Requires=network.target postgresql.service
    # "Wants" doesn't prevent to start if requirement isn't met
    # Wants=network.target postgresql.service
    # Configures service order (do X only after Y)
    After=network.target postgresql.service
    Before=nginx.service
    ConditionPathExists=/usr/sbin/commande
    Requires=media-YourMediaLabel.mount (une target)
    After=une target

    [Service]
    # Affichage dans l'environnement utilisateur
    # Déconseillé car systemd n'est pas là pour ça !
    # An application needs two things to open a window on an X display.
    # It needs to know the location of the X display; that's conveyed by the DISPLAY environment variable.
    # It also needs to authenticate with the X server. This is conveyed through a cookie,
    # which is a secret value generated by the X server when it starts and stored in a file that only
    # the user who started the X server can access. The default cookie file is ~/.Xauthority.
    # http://unix.stackexchange.com/questions/85244/setting-display-in-systemd-service-file
    Environment=XAUTHORITY=/home/Lex/.Xauthority
    Environment=DISPLAY=:0

    Type=simple
    ExecStart=/bin/sh -c 'commande'
    TimeoutSec=0
    StandardOutput=tty
    RemainAfterExit=yes
    SysVStartPriority=99

    [Install]
    WantedBy=multi-user.target

• Recharger systemd:

systemctl --system daemon-reload

• Tenter de démarrer le service/l'activer au démarrage:

systemctl start mon-service.service
systemctl enable mon-service.service

Les niveaux d'exécution

Une cible systemd est un mode de fonctionnement du système (mode graphique, non graphique etc.) qui correspond à un démarrage d'un certain nombre de services. On reconnait ces unité par leur suffixe .target. Une cible permet de sépcifier un état sans avoir à gérer toutes les unités qui en dépendent.

Les alias commençant par « runlevel » sont là pour les gens qui ont l'habitude de SysVinit.

Identifier le niveau d'exécution courant

$ systemctl get-default
graphical.target ou multi-user.target

Changer le niveau d'exécution

init <x>
ou
systemctl isolate <target>

PS: Éventuellement vérifier les dépendances avant : cf Lister les dépendances d'une unité.

Raccourcis

Contrairement à isolate, ils préviennent les utilisateurs lors de l'exécution de la commande.

systemctl rescue
systemctl halt
systemctl poweroff
systemctl reboot

Ajuster la cible par défaut

Chaque cible est un état du système (cf ci-dessus).

Lister les cibles : cf Lister tous les services/cibles actifs.

Cible par défaut lors du boot (gérant la cascade de dépendances pour statisfaire l'état final du système):

$ systemctl get-default
multi-user.target

Changer la cible par défaut:

$ systemctl set-default graphical.target

Les services de systemd

Ajustement des niveaux d'exécution des services

Via le programme sysv-rc-conf ou en modifiant les scripts de contrôle dans /etc/init.d et les liens symboliques dans /etc/rc0.d ... /etc/rc6.d.

Les autres services à désactiver

Voici une liste en vrac des services que j'ai enlevés de ma machine. Bien évidemment, tous ces services ne sont pas présents sur toutes les installations.

• avahi-daemon.service (Activé par def):

  découverte des ressources du réseau local. Résolution DNS, partage de ressources sans passer par DHCP.

  => désactivé

• bluetooth.service (Activé par def):

  => désactivé

• pppd-dns/dns-clean (Activé par def):

  Si vous avez une connexion ADSL, ne vous serviront à rien. Ces derniers permettent surtout de gérer les connexions de type dial-up (ancien modem RTC).

  => désactivés

• ModemManager.service (Activé par def):

  Permet ? La connexion à un réseau 3G etc. probablement via modem-manager-gui. Si depuis le networkmanager cela ne fonctionne pas, il faudra réactiver le service. cf http://doc.ubuntu-fr.org/modem

  
  

  • Send and receive SMS messages with messages concatenation
  • Send USSD request and receive answer in system encoding
  • Get modem and SIM information (Device info, Operator name, Mode, IMEI, IMSI/ESN, Signal level)
  • Scan available mobile networks
  • Control data transmission process and set session traffic and time limits

  => désactivé

• rc-local.service (Activé par def):

  Gère les fichiers de boot rc.local (locate rc.local) Utilisation non recommandée, plus utilisés, et rien dedans. => je vire mais par défaut il est 'static' : il faut le masquer: systemctl mask rc-local.service

  Ce fichier sert souvent uniquement à activer le numlock dans les consoles tty; Corriger le service getty@.service semble être aujourd'hui une meilleure approche (ne spécifie pas le nb de consoles en dur dans le script) => voir plus bas le service getty.

• miredo.service (Activé par def):

  Support IpV6 sur les réseaux avec Nat qui ne le supportent pas. Compatibilité provisoire..

  => désactivé

• openvpn.service (Activé par def):

  => désactivé

• lvm2-monitor.service (Activé par def):

  Je n'utilise pas de volumes LVM.

  systemctl status lvm2-monitor.service retourne No volume groups found, idem pour lvm2-activation-early.service et lvm2-activation.service.

  => désactivés

• lvm2-lvmetad.service (Activé par def):

  => désactivé

• systemd-fsck@.service & systemd-fsck-root.service (Activés par def):

  Si vérification complète: affichage du % de fichiers contigus. En pratique ce n'est pas à systemd de faire la vérif à chaque fois; Le système de fichier ext a un compteur qui déclenche le scan.

  Ajout possible d'une ligne au kernel pour le système de fichier root: fsck.mode= One of "auto", "force", "skip". Controls the mode of operation. The default is "auto", and ensures that file system checks are done when the file system checker deems them necessary. "force" unconditionally results in full file system checks. "skip" skips any file system checks.

  En attendant, on peut ajouter aux options des partitions non essentielles dans le fstab: "noauto,x-systemd.automount" (pas sur root donc..)

  will buffer all access to that partition, and will fsck and mount it on first access, reducing the number of filesystems it must fsck/mount during the boot process.

  Note : this will make your /home filesystem type autofs, which is ignored by mlocate by default. The speedup of automounting /home may not be more than a second or two, depending on your system, so this trick may not be worth it.

  If you have a large /home partition, it might be better to allow services that do not depend on /home to start while /home is checked by fsck. This can be achieved by adding the following options to the /etc/fstab entry of your /home partition.

  PS: defaults = rw, suid, dev, exec, auto, nouser, async

  
  

  Improve_boot_performance. Fstab.

• sslh.service (Activé par def):

  Cette machine n'est pas un serveur écoutant sur 443 et 22 Si on l’utilise sur le port 443, cela permet de pouvoir se connecter en SSH en utilisant le port 443 (non filtré sur la plupart des réseaux contrairement au port 22) tout en pouvant servir des pages Web en HTTPS, avec une seule adresse IP.

  => pas besoin de gérer ce port knocking amélioré => viré

• thin.service (Activé par def):

  Serveur web écrit en ruby (metasploit).

  => viré

• arpwatch.service (Activé par def):

  Sert à surveiller l'activité sur le réseau (ARP spoof etc..)

  => viré (configuration difficile)

• redsocks.service (Activé par def):

  This tool allows you to redirect any TCP connection to SOCKS or HTTPS proxy using your firewall, so redirection is system-wide. transparent proxying for any outgoing TCP connection Améliore le comportement de Tor. Redirection de traffic etc..

  Why is that useful? I can suggest following reasons:

  • you use tor and don't want any TCP connection to leak
  • you use DVB ISP and this ISP provides internet connectivity
  • with some special daemon that may be also called "Internet accelerator" and this accelerator acts as proxy.

  À creuser mais inutile la plupart du temps

  => viré

• gdomap.service (Activé par def):

  Communication de process... utilise le fichier de conf: /etc/default/gdomap dedans: ENABLED=no

  => viré & purgé sudo apt-get remove --purge gnustep

• speech-dispatcher (Activé par def):

  Service du lecteur d'écran Orca

  => désactivé

• nfs-common.service (Activé par def):

  partager des données principalement entre systèmes de type UNIX mais des versions existent également pour Microsoft Windows™ et Mac. permettre l'utilisation d'un répertoire ou de tout le système de fichiers d'un ordinateur de manière totalement transparente, comme s'il s'agissait d'un disque dur connecté directement à votre ordinateur.

  ne doit être déployé que sur des réseaux sûrs. Quelle que soit la version, NFS est a déployer dans un réseau local et n'a pas de vocation à être ouvert sur internet.

  => Viré car pas utile dans l'immédiat. => Masqué car si le service n'est pas démarré précocément, il l'est durant la dernière phase de boot (en même temps que la connexion réseau..)

• console-kit-daemon.service & console-kit-log-system-start.service (Activé par def):

  Log les connexions des utilisateurs, redémarrages, les sessions..

  Stockage du journal: /var/log/ConsoleKit/ Readme: /usr/share/doc/consolekit/README

  => viré (mask)

• cron.service (Activé par def):

  Tâches planifiées

  => Laissé

• **remote-fs.target (Activé par def):

  Similar to local-fs.target, but for remote mount points.

  systemd automatically adds dependencies of type After= for this target unit to all SysV init script service units with an LSB header referring to the "$remote_fs" facility.

  systemd-fstab-generator(3) automatically adds dependencies of type Before= to all mount units that refer to local mount points for this target unit. In addition, it adds dependencies of type Wants= to this target unit for those mounts listed in /etc/fstab that have the auto mount option set.

  => désactivé

Numlock par défaut dans les tty

Modification du service getty@.service.

This is simpler than using a separate service (especially since systemd-198) and does not hardcode the number of VTs in a script.

• Create a directory for drop-in configuration files : /etc/systemd/system/getty@.service.d.

• Now add the following file & content in this directory : activate-numlock.conf

[Service]
ExecStartPre=/bin/sh -c 'setleds +num < /dev/%I'

Analyser les temps de chargement

systemd-analyze
systemd-analyze blame
systemd-analyze plot > plot.svg

Trouver les unit bloquantes pour le boot

systemd-analyze critical-chain

The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
graphical.target @22.577s
└─multi-user.target @22.577s
└─thin.service @18.431s +4.145s
    └─basic.target @14.329s
    └─paths.target @14.327s
        └─cups.path @14.327s
        └─sysinit.target @14.294s
            └─ufw.service @12.747s +1.547s
            └─local-fs.target @12.744s
                └─lvm2-monitor.service @12.478s +265ms
                └─system.slice @2.668s
                    └─-.slice @2.638s

Références

• Doc Ubuntu : Systemd.
• Doc Debian : Niveaux d'exécution/runlevels.
• Lea-linux : Systemd.
• Digitalocean : How to use systemctl to manage systemd services.
• Maketips : systemd.