Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Déconnexions intempestives

21ch181

Bonjour à tous,

Je cherche une solution à un pb qui est apparu récemment (suite à une coupure électrique bien que le serveur soit derrière un onduleur) et que je ne parviens pas à résoudre.

Sur mon réseau perso j'ai un serveur Ubuntu18.04 "cloud-init" (c'était la seule version que j'avais trouvée lorsque je l'ai installé sur une nouvelle machine il y a 2 ans) et des stations de travail sous Ubuntu Desktop 18.04.
Mes partages de fichiers sont réalisés avec NFS et la configuration des points de montage sur les stations étant réalisés avec AUTOFS.

Jusqu'à il y a 2 jours tout fonctionnait parfaitement et maintenant nous sommes régulièrement déconnecté du serveur après un court temps d'utilisation (de l'ordre de 1 mn). Il faut alors attendre environ 3-5 mn avant de pouvoir s'y reconnecter.
Quand je parle de connexion/deconnexion, je parle du navigateur de fichier (natif gnome ou nemo ou double-commander) comme de la console SSH.

J'ai regardé le log syslog et j'ai trouvé à chaque déconnexion la ligne suivante : CRON (root) CMD: if [-x /usr/bin/tuptime]: then /usr/bin/tuptime -x > /dev/null; fi
[Edit] : cette ligne dans Syslog revient précisément toutes les 5 mn

Avec mes maigres connaissances, j'en conclu qu'il y a une routine root qui déclenche une redirection en /dev/null dés lors que le user a dépassé un certain temps de connexion.

Aie je bien compris ?
Comment puis je affiner l'analyse de ce dysfonctionnement ?
Et surtout ... comment puis je y remédier ?

Je vous remercie d'avance pour votre aide précieuse

Cordialement

grandtoubab

c'est l'oeuf et la poule
tuptime c'est un outil de monitoring qui veut peut etre simplement enregistrer la deconnexion

https://github.com/rfrail3/tuptime/blob/master/tuptime-manual.txt
x, --silent update values into db without output

je ne pense pas que çe soit lui qui la provoque

bruno

+1
Pour les déconnexions intempestives il faut t d'abord regarder du côté du réseau : câbles, switch, etc.

21ch181

Merci pour vos idées.

J'ai effectivement changé le cable et corrigé la config de network du cloud-init et j'ai noté une amélioration : je suis pour voir la stabilité

Dans cette mouture, il y a une "certaine" ambiguité entre Netplan et Cloud-init pour la config réseau : tant qu'on reste en DHCP ca se passe bien mais quand on est en IP fixe, c'est autre chose ...

Cordialement

21ch181

Rebonjour,

Si vous avez d'autres idées, je suis preneur car mon prob n'est toujours pas résolu et il se situe du coté serveur : toutes les stations continuent à être pingables et peuvent pinguer n'importe quelle autre sauf pour le serveur lorsque sa connexion ne fonctionne plus.
Comme toutes les stations passent par les mêmes switchs, ca ne vient pas d'eux. Câble changé et pas d'amélioration.

Merci pour votre aide

bruno

Il faut donc identifier le problème qui fait que le serveur perd la connexion. Comme les raisons peuvent être très nombreuses il faut surveiller le logs du noyau (syslog dmesg, journalctl -k au choix), la charge du serveur, les services qui sont actifs, etc. et avant tout indiquer et vérifier la configuration réseau du serveur.

Si le problème est réellement apparu suite à une coupure électrique, je suggère de commencer par faire une vérification des systèmes de fichiers sur le serveur (fsck).

21ch181

Bonjour Bruno,

Merci pour ton retour. Entre temps j'ai modifié la configuration des cartes réseau du serveur :
- j'avais 2 cartes physiques mais 1 seule avait été configurée à l'origine en DHCP, puis je l'avais modifiée en fixe
- j'ai modifié /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg pour mettre les 2 cartes en DHCP

network:
  ethernets:
    enp2s0:
      addresses: []
      dhcp4: true
      optional: true
    enp4s2:
      addresses: []
      dhcp4: true
      optional: true
  version: 2

- j'ai rebooté le serveur

Là tout refonctionne normalement, sans perte de connexion, et avec les 2 cartes physiques opérationnelles.

Ce que je ne comprends pas pour le moment :
- l'adresse fixe initialement configurée sur ma carte 1 est toujours vue par une analyse réseau
- comment configurer une IP fixe, sans que cela ne génère de pb, sur cette version de serveur Cloud-init !

Cordialement

21ch181

Bon, j'ai résolu mon Pb !

J'ai réussi à repasser en IP fixe pour mon serveur, sur les 2 cartes réseaux et depuis plus de pb !
L'origine de mon pb : l'ancienne IP du serveur chevauchait la plage d'IP DHCP et suite à une coupure de courant (au delà de la capacité de l'onduleur ...), le serveur n'a pas réussi à reprendre son IP en 1er ... IP qui a été prise par un autre terminal (au passage nouveau sur mon réseau et que j'avais oublié dans ma config ...).
Ce qui me surprend malgré tout, c'est qu'habituellement quand un terminal prend une IP qui est déjà prise par un autre, il n'y a pas d’ambiguïté : le 2nd ne peut pas se connecter même par intermittence comme je l'ai vécu.

Voilà ce qui arrive quand on manque de rigueur et qu'on n'a pas de tête !!

Merci pour les pistes d'investigation.