🌐 Des déclenchement selon l'état du réseau

Introduction

Dans un précédent article, j’ai présenté le fait qu’il est possible sans grande difficulté de démarrer des services systemd avec des règles udev, ce qui est très pratique pour détecter le branchement d’un disque dur ou d’une carte sd.

Mais qu’en est-il quand on veut faire des actions liées au réseau ?

Cas 1 : Événement sur l’existence de l’interface réseau

Le point le plus simple et le plus similaire au cas précédent est de réaliser une action sur le “branchement” d’une interface réseau. Cela peut avoir du sens dans certains cas particulier tel que le partage de connection usb depuis un téléphone : L’interface n’existe que si le téléphone active l’option et disparaît à l’instant où le partage se termine.

Dans ce cas présent, la méthode la plus fiable est de jouer là aussi avec les règles udev. Mais si vous pouvez garantir la stabilité du nom de l’interface, par exemple avec networkd, une méthode plus simple existe :

En effet, le système présente les interfaces réseau sous la forme de device systemd. Il est ainsi possible d’utiliser ces éléments pour exécuter un service

Pour voir les interfaces réseaux découvertes sur votre machine par systemd :

systemctl | grep sys-subsystem-net-devices

Voyons donc comment faire dans un cas concrêt

Forcer un nom d’interface stable avec networkd

Par défault sur ma machine, le nom des interfaces usb de tethering sont systématiquement modifié à la reconnection ce qui n’est pas pratique dans notre cas.

Pour ce faire, je vais utiliser networkd car la configuration de celui-ci est très simple. Il est possible de forcer un nom d’interface stable avec networkd sans passer par de la configuration udev.

Petit aparté sur la cohabitation systemd-networkd / NetworkManager: Contrairement à ce que peut faire croire certaines documentations, il est aujourd’hui tout à fait possible de faire tourner à la fois network-manager et network-manager sur la même machine dans le même temps. Il faut juste clarifier quelle interface vous gérer avec quel outil. Network-manager excelle pour les configurations dynamiques (connection wifi par exemple), là où systemd-networkd est idéal pour des interfaces statiques. Cet état de gestion partiel par un outil abouti à ce que l’outil obtienne une vision réduite sur l’interface, mais il reste néanmoins conscient de leur existence. De ma connaissance le seul conflit qu’il peut être nécessaire de résoudre est d’éviter d’avoir à la fois systemd-networkd-wait-online.service et NetworkManager-wait-online.service actif en même temps.

Dans le cas présent, on fixe vis à vis du port usb car c’est plus simple, mais il est probablement possible de fixer cela mieux, néanmoins je manque de meilleures idées.

Pour cela, il faut évidemment que networkd soit activé, comme dit précédemment, ce n’est pas un gros soucis (du moins sous debian) même si vous utilisez déjà NetworkNanager:

/etc/systemd/network/10-netusb.link:

[Match]
# À ajuster avec le path obtenu pour l'interface avec udevadm info
# udevadm info /sys/class/net/enx02e17d08a1ad
Path=pci-*** 

[Link]
Name=netusb

/etc/systemd/network/10-netusb.network:

[Match]
Name=netusb

[Network]
DHCP=yes

Relancez networkd:

sudo systemctl daemon-reload && sudo systemctl restart systemd-networkd

Maintenant testons notre service

$HOME/.config/systemd/user/test_network.service:

[Unit]
Description=test_network
After=sys-subsystem-net-devices-netusb.device
BindsTo=sys-subsystem-net-devices-netusb.device

[Service]
Type=simple
ExecStart=echo "running"
RemainAfterExit=true

[Install]
WantedBy=sys-subsystem-net-devices-netusb.device

Il vous faut l’activez:

systemctl --user enable test_network

Maintenant si vous activez le partage réseau sur le téléphone le service démarrera. Il vivra même le temps de l’interface réseau grâce à BindTo et RemainAfterExit.

Cas 2 : Événement sur l’état du réseau / de l’interface réseau

Pouvoir réagir sur l’existence d’une interface réseau, c’est bien, mais pouvoir réagir sur l’état d’une interface réseau ça semble néanmoins un cas plus pertinent : Démarrer son service quand le réseau est actif, redémarrer un service si le réseau “saute”, lancer un script de backup local quand le réseau se déconnecte, etc.

network-online.target

La première intuition serait d’utiliser ce qui existe dès à présent dans systemd, la target “network-online.target”. Malheureusement, elle n’est utile que pour le premier accès au réseau de la machine :

Note that this unit is only useful during the original system start-up logic. After the system has completed booting up, it will not track the online state of the system anymore. Due to this it cannot be used as a network connection monitor concept, it is purely a one-time system start-up concept.

Cela peut être utile dans de nombreux cas cependant, mais ne couvre pas tous les usages.

Script “Dispatcher”

Faute de solution systemd qui semble purement intégré et standard, il faut donc soit :

• nous tourner vers des solutions dépendantes de nos outils réseaux : NetworkManager, systemd-networkd, …
• créer nous même notre solution logicielle pour répondre à ce problème.

Il existe quelques logiciels existant pour gérer ce genre de cas :

1. NetworkManager possède mécanisme de script dit “dispatcher” qui semble plutôt éprouvé.
2. Systemd-networkd ne possède actuellement (août 2025) pas de solution, mais des logiciels tiers comparables au dispatcher de NetworkManager existe :
   • networkd-dispatcher qui semble à priori un bon choix avec sa présence dans les dépôts, dans les fait le logiciel s’avère pour le moment décevant.
     • La gestion des interfaces qui change de nom est dysfonctionnelle.
     • Contrairement à NetworkManager, il semblerait qu’il soit obligatoire de placer les scripts dans des dossiers par état.
   • network-broker : non testé, en rust, mais qui semble basé sur la même logique que networkd-dispatcher donc probablement les mêmes problèmes, pas beaucoup de développeurs.
   • network-event-broker : Non testé , en go, créé par vmware.

Dans tous les cas, il s’agit là de script bash pour gérer le réseau. Ce n’est pas le plus élégant, mais il est évidemment envisageable de convertir ces scripts pour lancer/arrêter des target/service systemd correspondant à nos besoins.

Exemple: NetworkManagers Dispatcher

Un petit exemple pour forcer un logiciel à se redémarrer si une nouvelle connexion gérée par NetworkManager est “UP” :

/etc/NetworkManager/dispatcher.d/01-restart-myservice-on-new-network-up :

#!/bin/bash
case $2 in
  up)
    systemctl try-restart --no-block myservice.service
  ;;
  *)
    ;;
esac
exit 0

La solution idéale ?

La solution qui me paraîtrait idéal pour des cas simple, serait tout simplement d’avoir un service :

• capable d’écouter en dbus sur les évènements networkd.
• capable via ces données d’activer/désactiver des target systemd correspond au fait que l’interface réseau fonctionne.

Une implémentation assez simple de ma part se trouve ici En démarrant le script python listen_events.py via le service networkd_listener.service (il vous faut dbus-fast),

les targets suivantes sont gérés :

• networkd_status.service correspond à l’état général de la connectivité de la machine (faire partie d’un réseau). le service est actif si l’ “OperationalState” général est “routable”.
• networkd_link_status@[interface_name}.target correspond à l’état de la connectivité d’une des interfaces. le service est actif si l’ “OperationalState” de l’interface est “routable”.

Avec une telle solution, on ne peut pas forcément gérer des cas fin de réseaux, mais on peut gérer relativement simplement le cas qui seront probablement le plus commun :

Démarrer/arrêter des services selon si le réseau est actif ou nom, généralement ou pour une interface spécifique.

On peut imaginer par exemple une autre version du service test_network qui ne fonctionne que si l’interface usb est fonctionnelle (et non existante comme dans l’exemple précédént) :

[Unit]
Description=test_network
After=networkd_link_status@netusb.target
BindsTo=networkd_link_status@netusb.target

[Service]
Type=simple
ExecStart=echo "running"
RemainAfterExit=true

[Install]
WantedBy=networkd_link_status@netusb.target

Et Si l’interface réseau n’importe pas :

[Unit]
Description=test_network
After=networkd_status.target
BindsTo=networkd_status.target

[Service]
Type=simple
ExecStart=echo "running"
RemainAfterExit=true

[Install]
WantedBy=networkd_status.target

Cas 3 : Évènements sur la connectivité à l’internet

La version précédente, permet de faire fonctionner un service si le réseau existe (= possède une adresse) mais ne garantie pas de l’accès internet est bel et bien présent.

On peut imaginer une solution simple pour ce cas :

• un script python utilisant ping testant de temps en temps la connectivité
• un service systemd qui utilise ce script.

ping_test.py:

#!/usr/bin/env python3

import os
import random
import subprocess
import time
import datetime

def test_targets(targets, count) -> bool:
    """
    Tests connection to target, return true if one of the target is reachable
    """
    for target in targets:
        ping_process = subprocess.run(["ping", "-c", f"{str(count)}", target])
        if not ping_process.returncode:
            return True
    return False

ping_targets = os.environ.get("PING_TARGETS", "")
if not ping_targets:
    exit(1)
ping_targets = ping_targets.split(",")
heartbeat = int(os.environ.get("HEARTBEAT", "60"))
ping_count =  int(os.environ.get("PING_COUNT", "1"))

while True:
    random.shuffle(ping_targets)
    if not test_targets(ping_targets, ping_count):
        print(f"{datetime.datetime.now()} - HEARTBEAT FAILED")
        exit(0)
    print(f"{datetime.datetime.now()} - HEARTBEAT SUCCESS")
    time.sleep(heartbeat)

wan.service:

[Unit]
Description=Internet working ?
After=networkd_status.target
BindsTo=networkd_status.target

[Service]
Type=simple
# check with multiple url in case, one of them fail for internal reason
Environment=PING_TARGETS=inkey-art.net,perdu.com,perdus.com,linuxfr.org
# heartbeat in sec (verify connection each 2min)
Environment=HEARTBEAT=120
ExecStart=/opt/ping_test.py
Restart=always

[Install]
WantedBy=networkd_status.target

On peut d’ailleurs comme dans l’exemple ici profiter de l’existence de networkd_status.target pour éviter de ping quand le réseau est assurément non disponible.

Cas 4 : Évènement sur l’activation d’un socket.

Il reste un dernier cas, un peu différent, mais il me fallait l’aborder, d’autant qu’il est très bien intégré à systemd. C’est l’activation par socket.

L’idée n’est là pas tant d’agir sur le réseau au sens interface réseau, mais plutôt au sens connection, au sens socket.

Le principe de l’activation par socket est de pouvoir démarrer un service que si une connection au socket associé est ouverte.

J’y vois 2 grand intérêt :

• réduire la latence du boot (pas de nécessité de démarrer un démon ssh si le port ssh n’est pas contacté)
• réduire l’usage des services utilisé peu régulièrement. Je pense que la mémoire vive est probablement là où ça doit jouer le plus.

Ce cas est déjà bien présenté dans le blog d’ilManzo’s en anglais. Je vous conseille donc d’y jeter un œil.

Pour résumer rapidement la procédure :

• Il vous faut un fichier .service et un fichier .socket.
• Le fichier .socket doit être activé et démarré pour écouter sur le port voulu.
• Il faut adapter le code du serveur pour qu’il puisse utiliser le socket déjà ouvert.
• Il est possible via diverses astuces notamment systemd-socket-proxyd de gérer le service de sorte à qu’il s’arrête s’il n’y a plus d’activité sur le socket.

Conclusion

Creuser cette question m’a beaucoup amusé.

J’ai été un peu déçu du manque de complétion de systemd sur la partie événement lié au réseau, mais comme on le voit, il est possible assez facilement d’y remédier. On peut espérer néanmoins à l’avenir quelques mécanismes un peu plus solides et intégrer pour ce type d’évènement dans systemd. Le cas de vouloir démarrer un service à la connection/déconnexion d’une interface réseau ne me semble pas si extravagant que systemd ne mériterait une intégration de ce nom.

En attendant, il est possible de bricoler des targets et du service systemd pour un peu tout ce qu’on veut et ainsi avoir un système plus “réactif”.