kortex a écrit 103 commentaires

C'est étrange que Debian fournisse une version plus récente mais pourquoi pas :-)

Pour Ubuntu si je dois mettre à jour je ne vais pas avoir le choix que de passer par une installation manuelle (ou de chercher des paquets ailleurs).

Ok merci :)

Donc ce paramètre est en place depuis hier (15/11/2021) en début d'après-midi : wait and see :)

Je vous fais une réponse commune à tous les deux :)
Déjà merci pour les suggestions / les pistes.

si tu peux installer un peu de monitoring et faire des mesures :
- ping localhost
- latence CPU (je ne sais pas bien comment) ; peut-etre dans une boucle : sleep 1s ; et lire l'heure et voir s'il y a un décalage entre ce que devrait être l'heure et ce qui est lu ; ne pas hésiter a placer le process en priorité basse
- ping sur la route par défaut

Je vais effectivement voir si je peux mettre en place rapidement quelque chose car il peut effectivement y avoir des choses intéressantes.

Concernant les fournisseurs, malheureusement ce ne sont pas des fournisseurs publics comme OVH, etc.
Donc quand je dis que je n'ai accès à rien je n'ai accès à rien :-D : je ne sais même pas quelle technologie de virtualisation est derrière + quand je récupère les VMs l'OS est déjà installé / pré-configuré.

De plus, de part notre activité, nous avons plusieurs fournisseurs ce qui signifie que les machines sont peut-être sur des hyperviseurs différents, que les machines ont peut-être des configurations de bases différentes, etc. Bref, c'est pas simple…

Est-ce que je peux déplacer ma VM ? Clairement pas sauf à potentiellement faire une demande (en espérant que ce soit bien des VM et qu'il y ait une technologie type vMotion sur l'hyperviseur du fournisseur :-D) : je peux toujours poser la question demain :)

et si ca se trouve ton code sous tomcat8 (ubuntu 18) a des bugs sans effet, alors que sur la VM en ubuntu 20.04, avec le tomcat9, ces memes bugs sont 'pris' en compte

J'y pensais à ça mais il n'y a vraiment RIEN qui apparaît dans les logs c'est vraiment bizarre…
C'est juste que d'un coup on voit que ça mets une plombe à répondre…

Pour la fuite mémoire j'y ai pensé mais effectivement je maintiens : il n'y a aucun signe :-/

Le cycle est d'environ 2-3 jours : vendredi nous avons redémarré le tomcat vers 17H30 et de nouveau aujourd'hui vers 13H30 par exemple…

Le problème vient tout juste de se reproduire.
J'ai donc :

• mis à jour le JDK (avant = 8u282 ; après = 8u292)
• ajouté le paramètre acceptorThreadCount="2" dans server.xml

Reste à attendre et espérer :)

Qu'est ce que tu utilises comme gestionnaire de paquet?

J'utilise apt / apt-get (ce sont des serveurs Ubuntu).
Et malheureusement je suis sur la dernière version que donne Ubuntu : 9.0.31 (c'est pour ça que je garde en tête de taper une installation manuelle)

Qu'est ce que tu utilises pour déterminer la consommation des ressources CPU, disques, réseaux?

J'utilise des outils relativement classiques comme :

• top
• htop
• free
• df
• iftop
• iotop

Le partitionnement n'est pas identique au sens strict du terme car selon les machines les partitions n'ont pas exactement la même taille.

Par contre il y a le même nombre de partition, les même points de montage, les même filesystems (pour la partie qui nous intéresse c'est du XFS).

Aucun FS n'est à 100% ni quand ça fonctionne ni quand le problème apparaît.

J'ai oublié de le dire dans mon message initial mais au niveau du swap tout est vert aussi :)
En gros, la machine ne fait rien, mais Tomcat est lent :-/

Dans ton cas c'était aussi sur du Tomcat ?

Je vais essayer de me renseigner pour ce paramètre "acceptorThreadCount" et voir où il se mets : un grand merci ;)

Concernant le HTTPS oui s'en est mais quand on exécute une requête "locale" depuis le serveur tomcat en utilisant 127.0.0.1 alors on bypass la partie SSL et le problème est le même.
Ton idée est intéressante (et je t'en remercie) mais, et je peux me tromper, je ne pense pas que ça vienne de là :-/

Oui hier soir j'ai vu cette norme OnVIF et ça m'a l'air super intéressant aussi :)

Après c'est un peu au dessus du budget que je m'étais fixé mais comme dit je peux étendre dans une certaine limite si besoin.

Disons que le budget c'était plutôt pour "cibler" les réponses pour m'éviter la proposition d'une solution d'entreprise à 8000 € :-D

Hier j'ai trouvé des caméras OnVIF dans les 100 / 120 € ce qui est encore acceptable (disons que l'on ne passe pas de 50 € à 500 € quoi :-D).

Je pense commencer avec la caméra recommandée par seb et s'il le faut je la renverrai et m'intéressait à ce que j'ai trouvé compatible OnVIF.

Un grand merci pour ton aide :)

Bon ben tout ça me plaît bien : je vais commander ton modèle car ça m'a l'air de parfaitement répondre à mon besoin :)

En tout cas un grand merci pour ton retour d'expérience ;)

En faites pour l'instant je ne suis pas encore dans de l'enregistrement sur serveur etc :)

Pour l'instant consulter le flux live avec vlc et/ou ffmpeg me suffit :)
Puis peut-être que je vais être naïf mais je me dis que si la caméra cause avec un protocole à peu près standard alors je devrais réussir à m'en sortir si un jour je veux enregistrer :)

Alors c'est bizarre car sur ce site le modèle que j'ai acheté est référencé et j'avais essayé de requêter la caméra avec vlc (rtsp) mais ça n'a pas fonctionné. D'ailleurs un telnet sur le port 554 montrait que le port était fermé (confirmé avec nmap)…

Je vais regarder du côté de ton modèle :)
Je t'embête encore un peu : est-ce tu avais pu configurer le WiFi de la caméra sans l'application du constructeur ? Si oui ce serait top, si non je ferai un effort :D

Merci pour le retour :)

Par contre quand tu as acheté la sienne comment as-tu su qu'elle serait compatible avec ffmpeg / vlc ? Car en lisant la fiche Amazon rien ne le laisse penser…

Car je vais déjà en renvoyer une chez Amazon et je ne sais pas si au bout d'un moment ils ne vont pas m'envoyer bouler si ça ne va toujours pas :-D

Alors ça pourrait être une bonne solution par contre c'est tout de suite plus de boulot surtout si je veux une intégration pas trop vilaine.
J'avoue n'avoir regardé qu'en diagonal pour l'instant mais je n'ai pas l'impression qu'il soit facile de trouver un boitier pour intégrer proprement les modules caméra si ?

Et autre chose que j'ai peut être loupé mais le module Caméra v2 8MP n'a pas l'air d'avoir de mode nocturne :/
Alors j'en ai trouvé un nocturne sur KUBII mais on en revient au problème d'intégrer ça proprement.

C'est de ma faute je ne l'ai pas précisé dans mon post mais la rotation de la caméra victure était intéressant aussi :)

Je comprends la logique : d'ailleurs je déteste tomber sur un post dans lequel la personne ne réponds plus et où il n'y a pas la solution… :)

Bien que nous n'ayons pas plus approfondi la piste du tcpdump que ça, je pense que de toute façon la solution serait passée par une mise à jour de quelque chose.

Donc si quelqu'un a le même soucis, je pense que la solution c'était la mise à jour du kernel qui est venu avec CentOS 8.2 : il doit y avoir un patch dedans qui a réglé notre problème.

En espérant que ça aidera :)

Merci encore à tous pour l'aide apportée.

Bonjour,

Désolé pour cette longue absence mais j'ai été pas mal occupé ces derniers temps.

Alors désolé mais du coup nous n'avons pas réalisés le tcpdump pour l'instant : n'y voyez pas un message négatif du genre "il s'en moque de ce que l'on racconte".

C'est juste qu'en parallèle on testait pas mal de trucs (cf. tout l'historique) et que nous sommes arrivés à un résultat positif en faisant la mise à jour CentOS 8.1 -> 8.2.

Le rollback étant délicat, on préfère attendre de voir si le problème se reproduit pour jouer du tcpdump :) Pour l'instant nos tests ont été des succès mais attendrons le grand bain des refresh "naturels" (je crois que c'est ce week-end).

Nous avons pas mal galéré avec le tcpdump car même en essayant de le cibler sur les dernières minutes il produit trop de logs et nous n'avions pas la place de stocker sur cette machine…

Du coup on a continué de diguer sans.

A cet instant T pour résumer ce qui fonctionne
- kernel 4.18 d'origine + désactivation iptables
- kernel 5.6 compilé par nos soins
- kernel 4.19 compilé par nos soins

Et la nous avons testé autre chose… : update en CentOS 8.2 (bon timing ; ça a été releasé il y a peu) : 4 pg_restore ont fonctionné
Bon j'ai lu tout le changelog de RedHat et je ne vois rien qui puisse l'expliquer…

Mais du coup nous avons lancé un gros run de 12 pg_restore pour nous amener jusqu'à lundi et voir ce que ça racconte ;)

En faites il y a eu une imcompréhension entre un collègue et moi à propos du test avec "-A INPUT -j ACCEPT" :
- 3 pg_restore sur 4 ont fonctionné
- 1 pg_restore sur 4 a échoué avec la même erreur

Du coup c'est pas vraiment un succès :(

Il semble que cette piste (conntrack) soit la bonne :

• nous avons dégagé ces règles :

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

• nous avons remplacé par :

-A INPUT -j ACCEPT

Et nous avons réussi un lot de pg_restore ;)

Nous allons analyser les paramètres sysctl liés à conntrack: ça j'y crois pas vu que l'on avait copié toutes les valeurs.

Et nous allons essayer un kernel 4.19.

Sauf si tu as une meilleure piste ?

Je te remercie :)

Non on a pas essayé avec tcpdump.
Par contre on a joué du strace et on a déjà eu ce genre de choses :

recvfrom(6, 0x5172353, 5, 0, NULL, NULL) = -1 ECONNRESET (Connection reset by peer)
sendto(6, "\25\3\3\0\32\272\362\307j\311"..., 31, MSG_NOSIGNAL, NULL, 0) = -1 EPIPE (Broken pipe)

Nous pouvons effectivement essayer avec tcpdump mais je doute que l'on verra beaucoup de choses vu que nous sommes chiffrés en SSL. Nous verrons certainement une petite partie mais pas tout :)

Désolé je n'ai pas été très actif sur ce problème car fort occupé ces derniers jours.

Alors effectivement le résultat d'un iptables -L -n mets le doute sur ce fameux ACCEPT ALL et je comprends mieux ton raisonnement maintenant :)

Par contre je pense que c'est juste une sorte d'erreur d'affichage/d'interprétation car voici 100% des règles que l'on applique :

*filter
# POLICY
:FORWARD DROP [0:0]
:INPUT DROP [0:0]
:OUTPUT ACCEPT [0:0]

# ESTABLISHED
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# WHOLE INTERFACE IN AND OUT
-A INPUT -i lo -j ACCEPT

# WHOLE PROTOCOL
-A INPUT -p icmp -j ACCEPT

# WHOLE PORT
-A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT

# HOST AND PORT
-A INPUT -i eth0 -p tcp -s <ip1> --dport 9100 -j ACCEPT
-A INPUT -i eth0 -p tcp -s <ip2> --dport 5565 -j ACCEPT


# REJECT ANYTHING ELSE
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

Mes collègues ont continué les tests.

En compilant un kernel 5.6.14 en partant du fichier config de RedHat et en laissant le reste par défaut : le pg_restore fonctionne.

En remettant le kernel d'origine + en désactivant ce qui suit le pg_restore failed toujours :

-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Nous avons regardé à quoi ressemblaient les règles NFT sur le kernel d'origine et sur le nouveau (5.6.14) et il y a une différence.
On a donc essayé d'appliquer les même règles NFT sur le kernel d'origne : pg_restore failed toujours

Nous avons regardé à quoi ressemblaient les paramètres sysctl avec le nouveau kernel. Nous avons trouvé une différence qui aurait pu être intéressante :

net.ipv4.tcp_limit_output_bytes = 262144 --> net.ipv4.tcp_limit_output_bytes = 1048576

Nous l'avons testé sur le kernel d'origine et le pg_restore failed toujours.

Notre prochain test va consister à prendre la dernière release disponible sur kernel.org pour le kernel 4.18 + le compiler + tester :)

Nous venons de lancer l'essai en désactivant ces 4 règles d'iptables :

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

-> ça ne marche pas du tout : notre connexion se fait pas et on tombe en timeout.

Il a fallu faire ça :

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Désolé j'étais en congé hier et n'ai pas eu le temps de poster de nouvelles dans ce post.

Je ne comprends pas le soucis avec les règles iptables :/
Quand je disais que je n'étais pas le plus fort du monde j'ai oublié des mots : en réseau / pare-feu.

Tu me dis :

Il le faut si ta policy est en drop et que tu n'as rien d'autre qui match. Mais dans ton cas, tu as un INPUT en DROP mais une règle ACCEPT ALL. Du coup, c'est assez contradictoire.

Autant en OUTPUT, les deux règles semblent inutiles vu que l'on est en ACCEPT par défaut.
Autant en INPUT je ne comprends pas. L'idée est pas justement d'autoriser une connexion déjà initiée quand il y a un changement de port dans la chaîne ? L'exemple typique qui me viendrait est le cas de FTP.

On a pas encore essayé en désactivant ces règles mais on va tenter de tester ça aujourd'hui :)

Par contre, on a testé un kernel 5.6.14 compilé par nous et ça fonctionne.
On a pris le fichier config d'origine RedHat et pour toutes les nouvelles valeurs on a laissé les valeurs par défaut.

Il semble donc qu'il y ait quelque chose entre 4.18 et 5.6.

En réalité, nous avons ceci dans notre fichier iptables :

# ESTABLISHED
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

C'est plus historique qu'autre chose et ça n'a donc pas été mis en place pour que ça fonctionne car dès que le pare-feu est actif ça ne fonctionne plus.

Du coup tu faisais bien référence à la policy INPUT (la seule en drop par défaut) ?
Je suis pas le plus fort du monde mais il me semblait qu'il fallait ça pour maintenir les connexions établies fonctionnelles ?

Petites informations à jour :

• j'ai dit que le soucis se produisait après 4H30 : erreur de ma part - c'est 4H
• nous avons notre essai en cours avec un kernel à jour (5.6.14) : pour l'instant nous avons 3 succès sur 4 avec le pare-feu activé (nous sommes dans une boucle ; la dernière itération est en cours)

Bonjour,

Voici des retours de bon matin.

Concernant les règles de firewall en vigueur sur la machine :

# sudo iptables -L -n
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:22
ACCEPT     tcp  --  192.168.0.6          0.0.0.0/0            tcp dpt:9100
ACCEPT     tcp  --  192.168.0.7        0.0.0.0/0            tcp dpt:5565
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

Chain FORWARD (policy DROP)
target     prot opt source               destination         
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED

Concernant les valeurs de timeout :

• CentOS 8 :

net.netfilter.nf_conntrack_dccp_timeout_closereq = 64
net.netfilter.nf_conntrack_dccp_timeout_closing = 64
net.netfilter.nf_conntrack_dccp_timeout_open = 43200
net.netfilter.nf_conntrack_dccp_timeout_partopen = 480
net.netfilter.nf_conntrack_dccp_timeout_request = 240
net.netfilter.nf_conntrack_dccp_timeout_respond = 480
net.netfilter.nf_conntrack_dccp_timeout_timewait = 240
net.netfilter.nf_conntrack_frag6_timeout = 60
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_gre_timeout = 30
net.netfilter.nf_conntrack_gre_timeout_stream = 180
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_icmpv6_timeout = 30
net.netfilter.nf_conntrack_sctp_timeout_closed = 10
net.netfilter.nf_conntrack_sctp_timeout_cookie_echoed = 3
net.netfilter.nf_conntrack_sctp_timeout_cookie_wait = 3
net.netfilter.nf_conntrack_sctp_timeout_established = 432000
net.netfilter.nf_conntrack_sctp_timeout_heartbeat_acked = 210
net.netfilter.nf_conntrack_sctp_timeout_heartbeat_sent = 30
net.netfilter.nf_conntrack_sctp_timeout_shutdown_ack_sent = 3
net.netfilter.nf_conntrack_sctp_timeout_shutdown_recd = 0
net.netfilter.nf_conntrack_sctp_timeout_shutdown_sent = 0
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 120

• sur CentOS 7 :

net.netfilter.nf_conntrack_dccp_timeout_closereq = 64
net.netfilter.nf_conntrack_dccp_timeout_closing = 64
net.netfilter.nf_conntrack_dccp_timeout_open = 43200
net.netfilter.nf_conntrack_dccp_timeout_partopen = 480
net.netfilter.nf_conntrack_dccp_timeout_request = 240
net.netfilter.nf_conntrack_dccp_timeout_respond = 480
net.netfilter.nf_conntrack_dccp_timeout_timewait = 240
net.netfilter.nf_conntrack_events_retry_timeout = 15
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_sctp_timeout_closed = 10
net.netfilter.nf_conntrack_sctp_timeout_cookie_echoed = 3
net.netfilter.nf_conntrack_sctp_timeout_cookie_wait = 3
net.netfilter.nf_conntrack_sctp_timeout_established = 432000
net.netfilter.nf_conntrack_sctp_timeout_heartbeat_acked = 210
net.netfilter.nf_conntrack_sctp_timeout_heartbeat_sent = 30
net.netfilter.nf_conntrack_sctp_timeout_shutdown_ack_sent = 3
net.netfilter.nf_conntrack_sctp_timeout_shutdown_recd = 0
net.netfilter.nf_conntrack_sctp_timeout_shutdown_sent = 0
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180

• du coup la différence brut est la suivante :

< net.netfilter.nf_conntrack_frag6_timeout = 60
---
> net.netfilter.nf_conntrack_events_retry_timeout = 15
10,11d9
< net.netfilter.nf_conntrack_gre_timeout = 30
< net.netfilter.nf_conntrack_gre_timeout_stream = 180
13d10
< net.netfilter.nf_conntrack_icmpv6_timeout = 30
34c31
< net.netfilter.nf_conntrack_udp_timeout_stream = 120
---
> net.netfilter.nf_conntrack_udp_timeout_stream = 180

• donc les valeurs différentes sur CentOS 8 sont :

net.netfilter.nf_conntrack_frag6_timeout
  - présente uniquement sur CentOS 8
  - elle n'existe pas sur CentOS 7
  - ça semble concerner IPv6 et nous n'utilisons IPv6

net.netfilter.nf_conntrack_gre_timeout
  - présente uniquement sur CentOS 7
  - elle n'existe pas sur CentOS 8

net.netfilter.nf_conntrack_gre_timeout
net.netfilter.nf_conntrack_gre_timeout_stream
  - présentes uniquement sur CentOS 8
  - elles n'existent pas sur CentOS 7

net.netfilter.nf_conntrack_icmpv6_timeout
  - présente uniquement sur CentOS 8
  - elle n'existe pas sur CentOS 7
  - ça semble concerner IPv6 et nous n'utilisons IPv6

net.netfilter.nf_conntrack_udp_timeout_stream
  - valeur en CentOS 7 : 180
  - valeur en CentOS 8 : 120

Du coup je n'ai pas l'impression qu'il y ait quelque chose de ce côté là si ? Vous en pensez quoi ?

Il pourrait y avoir éventuellement nf_conntrack_udp_timeout_stream à monter à 180 mais nous avons déjà fait cela implicitement en appliquant tous les sysctl de CentOS 7 sur CentOS 8 :(