nmap laisse port TCP ouvert avec noyau 5.4.72

[pas sÍ»r que le titre soit le plus adéquat]

Bonjour,

Depuis quelques temps, en fait depuis mon passage d'un noyau 5.4.60-gentoo
Í  un noyau 5.4.72-gentoo, j'ai un bizarrerie dont je ne trouve ni cause
ni explication, mais surtout, qu'il m'est très expliqué d'expliquer Í  mon
ami google pour qu'il m'aide Í  trouver une solution.
J'explique la situation :
Sur chaque machine de mon réseau tourne un service gkrellmd, avec la
config par défaut sous Gentoo (port 19150 etc)
Sur ma machine de travail, je lance un gkrellm -s machine_distante pour
monitorer tout ça.
Et comme j'ai voulu automatiser tout ça, j'ai fait un script, avec une
boucle temporisée, qui se charge de vérifier les machines accessibles
parmi une liste définie, pour lesquelles gkrellmd est lancé, et dans ce
cas, lance le gkrellm -s $machine.
Dans mes tests, en plus d'un ping, j'utilise
nmap -n -sT -p 19150 $machine
dont je vérifie la sortie pour savoir si le port est ouvert.
Ce script fonctionne de la sorte depuis plusieurs années, sans aucun
problème. Donc, Í  priori, le script en lui même n'est pas en cause.

Or, il s'avère que pour toutes ces machines clientes (serveur gkrellmd),
depuis qu'elles sont passées en noyau 5.4.72 (qui est la version stable
actuelle chez gentoo), le simple fait de lancer ce nmap au préalable,
"plante" le gkrellm derrière.
Je m'explique :
Si en terminal je me contente de lancer gkrellm -s machine_distante, je
peux le faire, autant de fois que je veux, tout fonctionne, bien que j'ai
un message d'erreur :
Thu Nov 12 13:52:31 2020 Name com.canonical.AppMenu.Registrar does not
exist on the session bus
A chaque fois que cela fonctionne, j'ai ce message d'erreur.

Mais si je lance au préalable un simple nmap -n -sT -p 19150
machine_distante, je n'ai pas de message d'erreur, et aucun affichage
gkrellm, bien que le processus tourne.
Et lÍ , je peux tenter autant de fois que je veux, ça ne fonctionnera
jamais, jusqu'Í  ce que je relance le service gkrellmd.

J'ai même l'impression qu'il y a une notion de durée d'indisponibilité
qui augmente, parce que j'ai testé de :
- lancer nmap, d'attendre 10sec, de lancer gkrellm, ça fonctionne.
- la même Í  5sec, fonctionne aussi
- la même Í  3sec, ne fonctionne pas (je relance le service)
- refaire Í  5sec, ne fonctionne toujours pas (je relance le service)
- refaire Í  10sec, toujours pas (je relance le service)
- et après toutes ces tentatives infructueuses, j'ai relancé le service,
et après plusieurs minutes, j'ai enfin pu m'y connecter.

Sur 2 machines, j'ai mis un noyau dit instable (au sens gentoo) 5.8.16,
et le problème ne se pose plus, avec aucune des 2 machines.

Il m'est évidemment très compliqué d'étudier tous les changelog entre les
version 5.4.60 et 5.4.72 pour savoir ce qui est apparu qui pourrait
générer ce défaut, ou encore entre 5.4.72 et 5.8.16 pour savoir ce qui a
changé pour que ça retombe en marche.

J'ai bien voulu essayer d'autres options nmap puisque ça serait la cause,
mais il est évidemment exclu d'être obligé de l'utiliser en root juste
pour ça.
Mais si je lance au préalable en root, un nmap -n -sS -p 19150, puis le
gkrellm en user, aucun problème.
Donc, l'option -sT de nmap ouvre une connexion TCP, qui, avec ce noyau,
n'est pas refermée.
Mais comment transposer ça en requête google ?

Ou alors, si vous avez une proposition Í  me faire pour vérifier
l'ouverture d'un port distant avec un outil de base linux, je suis
preneur.

Merci de m'avoir lu, et de me pardonner les approximations techniques.
Evidemment, si besoin, je peux compléter mes explications, même si j'ai
tenté de tout dire.