Distribution EOLE

Quel est le retour de la commande "systemctl status netplan-wait-online.service" ?

Dans l’infrastructure de test, on constate un problème avec les commandes lancées par ce service (une série de /sbin/ethtool -s enp2s0 autoneg on qui n’est pas opérante, l’autonégociation n’étant pas disponible).

Pour autant, toujours dans l’infrastructure de test, ce problème n’aboutit pas à l’interruption du reconfigure. Il y a peut-être un autre problème.

Benjamin Bohard a écrit :

Quel est le retour de la commande "systemctl status netplan-wait-online.service" ?

Dans l’infrastructure de test, on constate un problème avec les commandes lancées par ce service (une série de /sbin/ethtool -s enp2s0 autoneg on qui n’est pas opérante, l’autonégociation n’étant pas disponible).

Pour autant, toujours dans l’infrastructure de test, ce problème n’aboutit pas à l’interruption du reconfigure. Il y a peut-être un autre problème.

Voici le retour de la commande :

× netplan-wait-online.service - Wait for Network to be Configured by Netplan
Loaded: loaded (/lib/systemd/system/netplan-wait-online.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Wed 2024-10-16 06:32:49 CEST; 4h 12min ago
Process: 1144 ExecStart=/lib/systemd/systemd-networkd-wait-online (code=exited, status=1/FAILURE)
Main PID: 1144 (code=exited, status=1/FAILURE)
CPU: 4ms

Est-ce que les logs affichés par la commande précédente indiquent une erreur du type :

set_linkspeed[18040]: netlink error: link settings update failed
set_linkspeed[18037]: netlink error: Invalid argument

Pour mémoire, les logs complets peuvent être affichés avec la commande "journalctl -u netplan-wait-online.service".

La configuration inadéquate des variables debit_carte_eth* étant la première hypothèse pour aboutir à une erreur du service, est-il possible de vérifier qu’elles sont cohérentes avec l’infrastructure réseau en place ? A priori, le premier point à vérifier est que l’autonégociation n’est pas utilisé si elle n’est pas supportée.

Les variables qui semblent intéressantes à ce stade sont (avec X remplacé par les numéros d’interface) :
- debit_carte_ethX_autoneg
- debit_carte_ethX_speed
- debit_carte_ethX_duplex

Les deux dernières ne sont accessibles que si la première est à non.

Benjamin Bohard a écrit :

Est-ce que les logs affichés par la commande précédente indiquent une erreur du type :
[...]

Pour mémoire, les logs complets peuvent être affichés avec la commande "journalctl -u netplan-wait-online.service".

La configuration inadéquate des variables debit_carte_eth* étant la première hypothèse pour aboutir à une erreur du service, est-il possible de vérifier qu’elles sont cohérentes avec l’infrastructure réseau en place ? A priori, le premier point à vérifier est que l’autonégociation n’est pas utilisé si elle n’est pas supportée.

Les variables qui semblent intéressantes à ce stade sont (avec X remplacé par les numéros d’interface) :
- debit_carte_ethX_autoneg
- debit_carte_ethX_speed
- debit_carte_ethX_duplex

Les deux dernières ne sont accessibles que si la première est à non.

Bonjour,

Les paramètres sont inchangés depuis l'installation du module il y a 1 an.
La variable autoneg est celle par défaut sur toutes les interfaces à oui.

Voici le rendu de la commande :
oct. 16 12:01:13 sre-amon systemd¹: Starting Wait for Network to be Configured by Netplan...
oct. 16 12:03:13 sre-amon systemd-networkd-wait-online¹⁰²²⁸⁰: Timeout occurred while waiting for network connectivity.
oct. 16 12:03:13 sre-amon systemd¹: netplan-wait-online.service: Main process exited, code=exited, status=1/FAILURE
oct. 16 12:03:13 sre-amon systemd¹: netplan-wait-online.service: Failed with result 'exit-code'.
oct. 16 12:03:13 sre-amon systemd¹: Failed to start Wait for Network to be Configured by Netplan.

Cela semble exclure les commandes ethtool des causes possible de l’erreur.
L’autre commande exécutée par le service netplan-wait-online.service est /lib/systemd/systemd-networkd-wait-online. Elle opère avec un timeout qui est celui atteint d’après le journal.

Une erreur similaire (décrite dans l’autre demande associée au même scénario) a été contournée (voire résolue) en modifiant un timeout (je ne sais pas encore si c’est celui de la commande /lib/systemd/systemd-networkd-wait-online).

Le timeout de cette commande est de 2 minutes par défaut (120 secondes). L’option --timeout peut être utilisée pour modifier cette valeur.

Vous est-il possible de tester la modification de ce timeout ?

Si oui, le plus simple est sans doute d’éditer le service via la commande "systemctl edit netplan-wait-online"
et de recopier entre les deux lignes de commentaire identifiant le contenu mis à jour :

[Service]
ExecStart=/lib/systemd/systemd-networkd-wait-online --timeout=500
ExecStart=-/usr/lib/eole/set_linkspeed

puis de recharger avec la commande "systemctl daemon-reload".
La commande "systemctl cat netplan-wait-online" doit faire apparaître cette mise à jour (ainsi que l’emplacement du fichier qui la déclare).

Benjamin Bohard a écrit :

Cela semble exclure les commandes ethtool des causes possible de l’erreur.
L’autre commande exécutée par le service netplan-wait-online.service est /lib/systemd/systemd-networkd-wait-online. Elle opère avec un timeout qui est celui atteint d’après le journal.

Une erreur similaire (décrite dans l’autre demande associée au même scénario) a été contournée (voire résolue) en modifiant un timeout (je ne sais pas encore si c’est celui de la commande /lib/systemd/systemd-networkd-wait-online).

Le timeout de cette commande est de 2 minutes par défaut (120 secondes). L’option --timeout peut être utilisée pour modifier cette valeur.

Vous est-il possible de tester la modification de ce timeout ?

Si oui, le plus simple est sans doute d’éditer le service via la commande "systemctl edit netplan-wait-online"
et de recopier entre les deux lignes de commentaire identifiant le contenu mis à jour :
[...]

puis de recharger avec la commande "systemctl daemon-reload".
La commande "systemctl cat netplan-wait-online" doit faire apparaître cette mise à jour (ainsi que l’emplacement du fichier qui la déclare).

Impossible de le modifier comme demandé :
Editing "/etc/systemd/system/netplan-wait-online.service.d/override.conf" canceled: temporary file is empty

Il ne prend pas en compte les modifications

Habituellement, cela vient de l’emplacement où sont effectués les ajouts. Voici l’allure globale du fichier dans mon test :

### Editing /etc/systemd/system/netplan-wait-online.service.d/override.conf
### Anything between here and the comment below will become the new contents of the file

[Service]
ExecStart=/lib/systemd/systemd-networkd-wait-online --timeout=500
ExecStart=-/usr/lib/eole/set_linkspeed

### Lines below this comment will be discarded

### /lib/systemd/system/netplan-wait-online.service
# [Unit]
# Description=Wait for Network to be Configured by Netplan
# DefaultDependencies=no
# Conflicts=shutdown.target
# Requires=netplan-apply.service
# After=netplan-apply.service
# Before=network-online.target shutdown.target
# 
# [Service]
# Type=oneshot
# ExecStart=/lib/systemd/systemd-networkd-wait-online
# ExecStart=-/usr/lib/eole/set_linkspeed
# RemainAfterExit=yes
# 
# [Install]
# WantedBy=network-online.target

L’ajout est effectué entre les deux lignes de commentaire suivantes :

### Anything between here and the comment below will become the new contents of the file

### Lines below this comment will be discarded

Benjamin Bohard a écrit :

Habituellement, cela vient de l’emplacement où sont effectués les ajouts. Voici l’allure globale du fichier dans mon test :
[...]

L’ajout est effectué entre les deux lignes de commentaire suivantes :
[...]
et
[...]

La modification a été prise en compte.
Pas de changement sur le service qui reste down.

Est-ce que la commande /usr/lib/systemd/systemd-networkd-wait-online, lancée à la main, donne le même résultat (sortie en erreur après le timeout) ?

L’idée derrière ce test serait de déterminer si le moment où la commande est lancée est déterminant.

Si la commande sort en erreur, quel est l’état des interfaces réseau ? Toutes en erreur, seulement quelques unes ?

La commande "networkctl list" devrait donner les informations pertinentes.

Pour aller plus loin dans la compréhension du problème (que je ne reproduis malheureusement pas encore dans l’infrastructure de test), il pourrait être utile d’observer ces états des interfaces lors du reconfigure. par exemple en exécutant dans un autre terminal la commande "watch -n0,5 networkctl list".

Dans mon test, par exemple, les interfaces restent à l’état routable (si il y a un changement, il est imperceptible au pas de 0,5 s de la commande watch).

IDX LINK   TYPE     OPERATIONAL SETUP     
  1 lo     loopback carrier     unmanaged 
  2 ens4   ether    routable    configured
  3 ens5   ether    routable    configured
  4 ens6   ether    routable    configured
  5 ens7   ether    routable    configured
 10 vlan21 vlan     routable    configured
 11 vlan22 vlan     routable    configured
7 links listed.

Benjamin Bohard a écrit :

Est-ce que la commande /usr/lib/systemd/systemd-networkd-wait-online, lancée à la main, donne le même résultat (sortie en erreur après le timeout) ?

L’idée derrière ce test serait de déterminer si le moment où la commande est lancée est déterminant.

Si la commande sort en erreur, quel est l’état des interfaces réseau ? Toutes en erreur, seulement quelques unes ?

La commande "networkctl list" devrait donner les informations pertinentes.

Pour aller plus loin dans la compréhension du problème (que je ne reproduis malheureusement pas encore dans l’infrastructure de test), il pourrait être utile d’observer ces états des interfaces lors du reconfigure. par exemple en exécutant dans un autre terminal la commande "watch -n0,5 networkctl list".

Dans mon test, par exemple, les interfaces restent à l’état routable (si il y a un changement, il est imperceptible au pas de 0,5 s de la commande watch).

[...]

Voici le résultat de la dernière commande :
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 ens160 ether routable configured
3 ens192 ether routable configuring
4 ens224 ether routable configured
5 ens256 ether routable configured

Apparemment une de nos interfaces est en configuring

Il est peut-être nécessaire d’élargir le champ d’investigation pour vérifier que la cause de la lenteur de configuration de l’interface n’est pas extérieure au module.

En guise de contournement temporaire, si un mode de fonctionnement dégradé (sans être assuré que cette interface fonctionne) est préférable à pas de fonctionnement du tout, il est possible d’exclure l’interface du test de la commande systemd-networkd-wait-online via l’option --ignore.

Benjamin Bohard a écrit :

Il est peut-être nécessaire d’élargir le champ d’investigation pour vérifier que la cause de la lenteur de configuration de l’interface n’est pas extérieure au module.

En guise de contournement temporaire, si un mode de fonctionnement dégradé (sans être assuré que cette interface fonctionne) est préférable à pas de fonctionnement du tout, il est possible d’exclure l’interface du test de la commande systemd-networkd-wait-online via l’option --ignore.

Nous avons beaucoup de routage sur cette interface.
Que teste concrètement le service ? est-ce que si une route ne répond pas, elle peut mettre en erreur le service ?

La commande bloque en attendant que les interfaces aient le statut "configured".

J’ai l’impression que la question principale, dans l’immédiat, est est-ce que l’interface ens192 finit par atteindre ce stade ?

Si oui, l’utilisation de l’option --ignore dans le service netplan-wait-online spécifiquement me paraît raisonnable pour passer l’étape du reconfigure.

Si non, il faut déjà vérifier l’état de l’interface pour juger si elle est apte à faire transiter les paquets ("networkctl status ens192" pour afficher les derniers logs).

Benjamin Bohard a écrit :

La commande bloque en attendant que les interfaces aient le statut "configured".

J’ai l’impression que la question principale, dans l’immédiat, est est-ce que l’interface ens192 finit par atteindre ce stade ?

Si oui, l’utilisation de l’option --ignore dans le service netplan-wait-online spécifiquement me paraît raisonnable pour passer l’étape du reconfigure.

Si non, il faut déjà vérifier l’état de l’interface pour juger si elle est apte à faire transiter les paquets ("networkctl status ens192" pour afficher les derniers logs).

Le résultat de la commande :
ens192
Link File: /usr/lib/systemd/network/99-default.link
Network File: /run/systemd/network/10-netplan-ens192.network
Type: ether
State: routable (configuring)
Online state: online
Alternative Names: enp11s0
Path: pci-0000:0b:00.0
Driver: vmxnet3
Vendor: VMware
Model: VMXNET3 Ethernet Controller
HW Address: (VMware, Inc.)
MTU: 1500 (min: 60, max: 9190)
QDisc: mq
IPv6 Address Generation Mode: none
Queue Length (Tx/Rx): 2/2
Auto negotiation: no
Speed: 10Gbps
Duplex: full
Port: tp
Address:
Activation Policy: up
Required For Online: yes

L'ajout :
[Service]
ExecStart=/lib/systemd/systemd-networkd-wait-online --ignore
ExecStart=-/usr/lib/eole/set_linkspeed

L'ajout :
[Service]
ExecStart=/lib/systemd/systemd-networkd-wait-online --ignore=ens192
ExecStart=-/usr/lib/eole/set_linkspeed

Ne permet pas de faire terminer le reconfigure

Pour l’instant, je ne vois pas quelles informations supplémentaires collecter pour faire avancer la compréhension du problème rencontré.

Sauf erreur, le constat est toujours le suivant :
- le service netplan-wait-online finit toujours en erreur et entraîne l’arrêt du reconfigure ;
- la partie ethtool du service netplan-wait-online n’est pas en cause (pas d’erreurs associées à netlink dans les logs) ;
- la partie systemd-networkd-wait-online pourrait être en cause (mis en cause par le timeout dans les logs) mais :
- l’augmentation du timeout ne permet pas de contourner l’erreur ;
- la non prise en compte de l’interface qui reste à l’état configuring ne permet pas de contourner l’erreur.

Si les contournements ont bien été appliqués, ça implique probablement que la piste du service n’est pas la bonne ou, au moins, pas suffisante.

Benjamin Bohard a écrit :

Pour l’instant, je ne vois pas quelles informations supplémentaires collecter pour faire avancer la compréhension du problème rencontré.

Sauf erreur, le constat est toujours le suivant :
- le service netplan-wait-online finit toujours en erreur et entraîne l’arrêt du reconfigure ;
- la partie ethtool du service netplan-wait-online n’est pas en cause (pas d’erreurs associées à netlink dans les logs) ;
- la partie systemd-networkd-wait-online pourrait être en cause (mis en cause par le timeout dans les logs) mais :
- l’augmentation du timeout ne permet pas de contourner l’erreur ;
- la non prise en compte de l’interface qui reste à l’état configuring ne permet pas de contourner l’erreur.

Nous allons monter une machine en parallèle pour tester si cela vient de notre système.
Je vous tiens au courant.
Merci pour l'aide

Si les contournements ont bien été appliqués, ça implique probablement que la piste du service n’est pas la bonne ou, au moins, pas suffisante.

Kevin KERFYSER a écrit :

Benjamin Bohard a écrit :

Pour l’instant, je ne vois pas quelles informations supplémentaires collecter pour faire avancer la compréhension du problème rencontré.

Sauf erreur, le constat est toujours le suivant :
- le service netplan-wait-online finit toujours en erreur et entraîne l’arrêt du reconfigure ;
- la partie ethtool du service netplan-wait-online n’est pas en cause (pas d’erreurs associées à netlink dans les logs) ;
- la partie systemd-networkd-wait-online pourrait être en cause (mis en cause par le timeout dans les logs) mais :
- l’augmentation du timeout ne permet pas de contourner l’erreur ;
- la non prise en compte de l’interface qui reste à l’état configuring ne permet pas de contourner l’erreur.

Nous allons monter une machine en parallèle pour tester si cela vient de notre système.
Je vous tiens au courant.
Merci pour l'aide

Si les contournements ont bien été appliqués, ça implique probablement que la piste du service n’est pas la bonne ou, au moins, pas suffisante.

Bonjour,

Nous avons fini par mettre la main sur le problème. C'est bien une route réseau qui en était la source ..
Dès que nous l'avons supprimé le reconfigure est allé à son terme.

Je ne sais pas comment mais les routes ont l'air d'avoir un effet lors des tests par ce service.

Ce que nous avons pu constater c'est que par conséquent le reconfigure ne va pas à son terme.
Nous n'avons pas pu Bypasser l'étape ce qui obligé à redémarrer le serveur qui se mettait en mode dégradé.
Les instances du Guardian n'étaient pas créées. Nous n'avions donc plus de filtrage avec le proxy. Alors que le diagnose ne remontait aucune erreur.

Est-ce qu'une amélioration du diagnose ainsi que des remonter dans le zéphir peuvent être envisagées ?

en tout cas, merci pour le suivi et l'aide apportée. Nous avons pu réduire et exclure les périmètres au fur et à mesure.

Je reformule pour vérifier que la conclusion est partagée :

Si la configuration réseau bloque le reconfigure, il faut que la cause soit mieux identifiée pour permettre sa correction. L’identification doit, a minima, est faite via le diagnose si le reconfigure ne donne pas les détails.

Je mets de côté volontairement l’approche contournement parce que ça me paraît difficile, a priori, d’avoir une évaluation de ce qui peut être contourné.

À ce stade, je ne sais pas encore ce qui peut être fait.

En complément d’informations, est-il possible de savoir quel était le problème de la route réseau ? inexistance, lenteur, filtrage, etc. ?