Bonjour,
Je viens chercher les conseils et j'espère solutions auprès de personnes plus compétentes que moi au sujet d'un serveur dédié.
### Situation
J'ai très récemment réinstallé mon serveur Kimsufi pour passer sous un Debian 12 bookworm. J'ai pu réaliser toutes les opérations de réinstallation et configuration avec l'aide d'un proche.
Nous avons d'ailleurs rencontrés plusieurs soucis et difficultés, notamment concernant les DNS et les iptables, qui firewall activé, bloquent beaucoup de choses sans explication, mais ce n'est pas la raison de ma venue.
### Problème
Sans raison apparente, le serveur devient absolument inaccessible d'une seconde à l'autre, plus joignable. Confirmé avec l'email des technicien[ne]s d'OVH, m'indiquant que le serveur ne répond plus au ping.
### Pistes explorées
Mon premier reflex est de chercher des logs système pour trouver une piste. Tous les logs serveur se trouvent bien dans `/var/log/*`? Avec le grand nombre de fichiers et dossiers ici, où chercher ? J'ai jeté un oeil à `syslog` et `cron.log`, mais je reste dans le flou… S'agit-il d'un crash ? Cela y ressemble, mais comment vérifier.
La seule "solution" actuelle est de reboot à froid la machine, ce qui n'est vraiment pas folichon…
Que faire ?
Précision à mon sujet, mes compétences sont assez basiques, je me débrouille pour gérer ou installer de nouveaux éléments, mais concernant l'installation et la configuration du système, ou la recherche de panne et debugging (le cas ici), je dois malheureusement admettre être dans l'obscurité.
Un grand merci d'avance pour l'aide ou les conseils potentiellement apportés !
Bonjour,
Au bout de combien de temps la machine devient inaccessible ?
Et sans aucune règle Iptables ça donne quoi ?
Bonjour,
Confirmé avec l'email des technicien[ne]s d'OVH, m'indiquant que le serveur ne répond plus au ping.
le rapport d'intervention sur le serveur indique quoi ?
Cordialement, janus57
Bonjour,
Le délai est assez aléatoire, la première fois c'est survenu une trentaine d'heures plus tard, mais il ne semble pas tenir plus d'à-peu-près un jour.
Actuellement, travaillant de nuit, je commence ma journée et je découvre avec consternation qu'il est encore tombé, plus joignable. Je viens de reboot hard.
Avant-dernière coupure cette nuit vers 01:05, j'étais connecté.
Nouvelle coupure/crash aujourd'hui vers 09:50, d'après mes stats réseau sur mon panel (cf. image ci-dessous).
Cette fois-ci c'est arrivé vraiment plus rapidement.
Effectivement j'ai oublié de préciser, pour l'instant il n'y a aucun firewall, iptables vides justement pour tester et avancer. Le fichier `rules.v4` n'existe tout simplement plus, on l'a backup.
Bonjour,
Côté OVH, voici les infos que j'ai dans leur deuxième email :
> Voici les détails de cette opération :
> Reboot HARD
> Date 2024-08-03 01:28:33 CEST (UTC +02:00), Reboot HARD:
> Voici le détail de l'intervention réalisée:
> Pas d'information à l'écran ("écran noir"). Pas de réponse au clavier.
> Actions entreprises:
> Redémarrage hardware du serveur.
> Résultat:
> Boot OK. Serveur sur 'login'. Ping OK, services démarrés.
Je vous joins, ci besoin, la dernière partie des logs provenant de `syslog` :
https://pastebin.com/eej1a28e
Merci beaucoup pour vous réponses !
Bonjour,
avez-vous fait les tests hardware pour éliminer un problème matériel ?
Cordialement, janus57
Bonjour,
J'avoue ne pas y avoir pensé. Ayant ces comportements depuis la réinstallation, je pense inconsciemment avoir écarté cette piste, pourtant pas impossible dans l'absolu.
Je vais me documenter ce soir, une fois pleinement disponible pour réaliser ce type de test sur ma machine et essayer de trouver quelque-chose de ce côté là !
Merci encore
A dedicated server becoming unreachable from one second to the next could indicate a crash or sudden network issue. Possible causes include hardware failure, software bugs, resource exhaustion (CPU, memory), network disruptions, or security breaches. To diagnose, check server logs, monitor resource usage, and ensure network stability. Immediate actions include rebooting the server, updating software, and running diagnostics to identify and resolve the underlying issue.
Bonjour,
Par contre il y a des choses intéressantes dans vos logs.
Est-ce qu'il serait possible de donner la liste avec date et heure de quand le serveur a arrêté de répondre ?
Car d'après vos logs je dirais que la liste est (si le serveur étais a l'heure) :
- 03/08/2024 à 1h58
- 03/08/2024 à 7h57
Cordialement, janus57
Je vous joins, ci besoin, la dernière partie des logs provenant de syslog :
2024-08-03T13:42:21.614231+00:00 ns305546 ifup[444]: DHCPREQUEST for ■■.■■■.■■■.■■ on enp4s0 to 255.255.255.255 port 67
2024-08-03T13:42:21.614313+00:00 ns305546 dhclient[444]: Sending on Socket/fallback
2024-08-03T13:42:21.614391+00:00 ns305546 dhclient[444]: DHCPREQUEST for ■■.■■■.■■■.■■ on enp4s0 to 255.255.255.255 port 67
2024-08-03T13:42:22.333543+00:00 ns305546 avahi-daemon[397]: Server startup complete. Host name is ns305546.local. Local service cookie is 3878511952.
2024-08-03T13:42:23.421342+00:00 ns305546 kernel: [ 19.705898] e1000e 0000:04:00.0 enp4s0: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
2024-08-03T13:42:24.623534+00:00 ns305546 dhclient[444]: DHCPREQUEST for ■■.■■■.■■■.■■ on enp4s0 to 255.255.255.255 port 67
2024-08-03T13:42:24.623729+00:00 ns305546 ifup[444]: DHCPREQUEST for ■■.■■■.■■■.■■ on enp4s0 to 255.255.255.255 port 67
2024-08-03T13:42:28.495828+00:00 ns305546 dhclient[444]: DHCPREQUEST for ■■.■■■.■■■.■■ on enp4s0 to 255.255.255.255 port 67
2024-08-03T13:42:28.495974+00:00 ns305546 ifup[444]: DHCPREQUEST for ■■.■■■.■■■.■■ on enp4s0 to 255.255.255.255 port 67
2024-08-03T13:42:28.498719+00:00 ns305546 dhclient[444]: DHCPACK of ■■.■■■.■■■.■■ from ■■.■■■.■■■.252
2024-08-03T13:42:28.498864+00:00 ns305546 ifup[444]: DHCPACK of ■■.■■■.■■■.■■ from ■■.■■■.■■■.252
Pouvez-vous fixer votre adresse IP en dur, et évacuer DHCP ?
Bonjour,
Pouvez-vous fixer votre adresse IP en dur, et évacuer DHCP ?
Ici c'est pas le problème immédiat car la machine ne répond plus quand le tech OVH est dessus.
Cordialement, janus57
Ici c'est pas le problème immédiat
Si le link est en 100 Mbit full duplex il s'agit sans doute d'un kimsufi, donc pas de KVM/IPMI non plus.
Bonjour,
Il a dit qu'il avait un Kimsufi.
Mais là vu les logs avec des traces de shutdown je dirais qu'il y a quelque chose sur la machine.
Par contre vu que c'est un Debian12 il faudrait aussi regarder les logs avec journalctl car mes Debian12 n'ont plus de syslog par défaut si je passe par le netinstaller.
Cordialement, janus57
```
2024-08-03T13:42:28.685637+00:00 ns305546 ifup[394]: ip -6 addr add 2001:41d0:2:8367::1/56 dev enp4s0
2024-08-03T13:42:28.687858+00:00 ns305546 ifup[537]: RTNETLINK answers: Permission denied
[…]
2024-08-03T13:42:28.702890+00:00 ns305546 systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
2024-08-03T13:42:28.765055+00:00 ns305546 systemd[1]: networking.service: Failed with result 'exit-code'.
2024-08-03T13:42:28.765304+00:00 ns305546 systemd[1]: Failed to start networking.service - Raise network interfaces.
```
Bonjour, vous avez désactivé l'IPv6 d'une manière ou d'une autre sans enlever l'IPv6 de `/etc/network/interfaces.d/50-cloud-init`. À cause de ça, au démarrage :
* `networking.service` démarre, il prend une IPv4 en DHCP
* Le serveur tente d'assigner une IPv6 mais ça plante, on a l'erreur vue dans le log concernant l'IPv6, le service passe en erreur
* Le client DHCP se fait tuer
* 24 heures plus tard (le temps du bail DHCP), l'IPv4 obtenue en DHCP expire et le client DHCP est mort donc vous perdez le réseau
C'est un problème assez classique sous Debian. Je vous conseille simplement d'enlever la configuration IPv6 si vous n'en avez plus besoin.
Bonjour, vous avez désactivé l'IPv6 d'une manière ou d'une autre sans enlever l'IPv6 de /etc/network/interfaces.d/50-cloud-init. À cause de ça, au démarrage :
* networking.service démarre, il prend une IPv4 en DHCP
* Le serveur tente d'assigner une IPv6 mais ça plante, on a l'erreur vue dans le log concernant l'IPv6, le service passe en erreur
* Le client DHCP se fait tuer
* 24 heures plus tard (le temps du bail DHCP), l'IPv4 obtenue en DHCP expire et le client DHCP est mort donc vous perdez le réseau
C'est un problème assez classique sous Debian. Je vous conseille simplement d'enlever la configuration IPv6 si vous n'en avez plus besoin.
Bonjour @le_sbraz ,
Merci pour cette analyse.
Est-ce que par hasard tous les problèmes déjà vus ici concernant des lease DHCP qui ne se renouvellent pas (avec perte de connectivité évidemment) seraient-ils dus à ce problème d'IPv6 ???
Just my 2 €cents
Est-ce que par hasard tous les problèmes déjà vus ici concernant des lease DHCP qui ne se renouvellent pas (avec perte de connectivité évidemment) seraient-ils dus à ce problème d'IPv6 ???
Une grande partie, oui :) C'était lié à l'autoconfiguration IPv6
Ça a été corrigé par :
https://salsa.debian.org/debian/ifupdown/-/commit/fe9fb5882ab5d238122d986454b0d156477bc8d0
https://salsa.debian.org/debian/ifupdown/-/commit/3fb794b2dc1f16da09409522826142ef5e226ddc
Aujourd'hui, quand le problème se produit, c'est que le client a cassé d'une manière ou d'une autre la configuration réseau (quand les modifications sont faites _après_ la configuration DHCP).
A priori, ce genre de problème ne se produit pas avec Netplan qui est quand même plus robuste et refuse complètement de démarrer. Donc sur nos installations Debian 12, on n'aura jamais ce comportement (ce n'est pas le cas d'@AlexandreDBP qui semble avoir upgradé une Debian 11 utilisant encore ifupdown) .
Donc sur nos installations Debian 12, on n'aura jamais ce comportement
Sur un proxmox installé le 11 février de cette année à partir de votre distribution, c'est bien Debian12 et /etc/network/interfaces (ce qui m'arrange car je n'ai pas encore viré ma cuti !)
Bonjour,
Proxmox n'utilise pas netplan c'est peut être le pourquoi du comment.
Cordialement, janus57
En effet alors là c'est encore différent, Proxmox utilise ifupdown2 ! C'est une réécriture de ifupdown en Python. À ne pas confondre avec ifupdown-ng utilisé par Alpine 
Bonjour,
Merci pour toutes vos réponses aujourd'hui, nous allons explorer chaque message avec mon collègue cette nuit.
Il y a une piste qui m'intéresse fortement, celle de votre message le_sbraz, concernant l'IPv6, nous allons également essayer ça après une nouvelle vérification matériel et possiblement de réinstaller une image de Debian 12 originale manuellement.
Pour information, il est de nouveau tombé il y a 30mn, à 50h55,
Le 4 aout à ~19h50,
Le 3 août à ~01h00,
Le 2 août à ~01h00.
…
Ce que m'expliquais la personne qui m'assiste fortement dans ce dossier, c'est qu'il n'y a qui rien dans les logs, donc un crash ou une panne si critique que le système n'a pas le temps d'enregistrer quoi que ce soit.
Ce serveur dédié, je l'ai déjà depuis une dizaine d'années maintenant. C'est quand même étrange, bien que toujours possible bien évidemment, qu'il s'agisse d'une panne côté hardware au moment même exact où on réinstalle tout au propre et à jour… Le check de ce soir nous le dira.
Un grand merci d'avoir pris le temps d'examiner ces logs de l'enfer…
Je vais bosser dessus cette nuit et vous tiens au courant !