Reprise du message précédent :

Merci.  
Je ne vois rien de suspect la plupart du temps, mais parfois oui. Voici un tracé pour un simple wget sur startpage.com. Pourquoi nom d'un rongeur il me fait plusieurs requêtes DNS identiques avant de contacter le serveur (GET) finalement? Ca a pris 3h (enfin presque ) et le tracé le confirme:
https://img.super-h.fr/images/2024/ [...] d35e25.png  
(Les paquets filtrés c'était du traffic sans lien avec ce test.)
Le ...169.12 est mon résolveur DNS primaire.
Je précise que j'avais désactivé IPv6 lors de ce test (sudo echo 1 | /sys/<machin_truc_je_sais_plus > ).
   
 
EDIT: Question annexe, vu que je suis derrière une box je peux désactiver mon pare-feu sur le PC non? Car je me demande si c'est pas du moins une partie du problème.

dans ta trace tu ne vois jamais de réponse aux requêtes AAAA (même en regardant plus loin dans le temps, genre jusqu'à 1 minute après la requête) ? Je pense que c'est anormal, et c'est peut-être ça que ton poste attend pour passer à la suite (avant de considérer que c'est un timeout). Ça n'explique pas pourquoi il fait plusieurs fois la requête A alors qu'il a déjà obtenu une réponse, mais ça pourrait être une implémentation un peu simpliste (ou une raison qui m'échappe).

Les moments où ça fonctionne, tu as une réponse à la requête AAAA ?

Je viens de tester avec dig en demandant un AAAA pour startpage.com à 80.67.169.12, j'obtiens un résultat similaire : absence de réponse, puis au premier retry j'obtiens une réponse immédiate, et si je refais la requête ensuite j'obtiens une réponse immédiate à nouveau. Donc on dirait que le résolveur FDN met trop de temps à déterminer qu'il n'existe pas d'enregistrement AAAA pour ce domaine, puis finit par mettre la réponse vide en cache et ensuite fonctionne du coup normalement.
Pourtant quand on fait la même demande aux 8 DNS de startpage.com, ils répondent immédiatement, donc il ne semble pas y avoir de problème à ce niveau. Donc le souci serait plutôt côté FDN semble t-il  

Tu connais d'autres domaines avec lesquels le problème est reproductible ? Je suppose qu'une fois que le DNS FDN a la réponse en cache, on ne peut plus reproduire le problème avant qu'elle n'ait expiré...

Faut dire à wget de faire la requête en ipv4 seulement

C'était effectivement ça, il avait switché la esr sur le repo de mozilla et avoir les 2 versions en 128 ( ou avoir firefox esr + firefox "standard" ) sur le repo mozilla posait problème.

J'ai désinstallé la version ESR du coup et c'est bon tout refonctionne.

Si tu veux désactiver ipv6, rajoute ipv6.disable=1 à ta ligne de boot dans grub.
Les autres solutions marchent pas super bien.

Bon je sais pas pourquoi mais je demande on sait jamais, on fait nos install avec un preseed au lycée là. Et d'une machine à l'autre au niveau du résultat final des fois on a gedit et des fois pas. (sans le mettre dans les pkgsel/include mais bon normalement ça vient avec Gnome)

Alors que c'est exactement le même preseed

Ya peut être un truc sur le fait qu'on installe tous les DE ? Ya une note officielle sur des DE installés ensemble qui foutrait la merde ?
Au niveau de notre miroir dans les logs de Nginx je ne vois aucune erreurs de transmission du paquet gedit.

 
il se met à jour tout seul sans poser de problème

 
Mais ça ne change pas uniquement la capacité du noyau à communiquer en IPv6, ce genre d'option ? Parce que là tous ses échanges se font déjà en IPv4

Telle que j'analyse la trace, wget essaye d'obtenir l'ipv6 depuis les DNS (AAAA), par 3 fois, mais n'obtient jamais cette réponse. Et après 15 secondes il fait un fallback en ipv4.
A valider avec un wget -v pour voir ce qu'il fait,  et des wget -4 pour forcer l'utilisation d'ipv4.
Tester aussi avec curl qui à priori à une meilleure gestion du fallback (200ms).

Merci pour vos réflexions, je vais continuer mes investigations cet après-midi ou soir et je vous dirais.

je reproduis bien le problème avec dig et startpage.com, j'ai même pu faire un pcap.
Tu peux déjà exclure pas mal de problèmes liés à ton installation locale du coup.

Par contre j'ai essayé de reproduire le problème en créant un nom qui a un enregistrement A mais pas de AAAA (comme startpage.com) sur un domaine perso et faire une requête AAAA dessus avec dig, mais dans ce cas je ne constate pas le souci, la résolution se fait directement. Donc le problème serait peut-être limité à certains domaines. Ça serait intéressant de laisser tourner longtemps chez toi pour voir si on peut identifier s'il y a des domaines en particulier qui posent des soucis, et éventuellement trouver des points communs entre eux.

Il y a des gens qui utilise Mate Desktop ?
Suis sur Gnome 4 mais j'ai envie d'y repasser. Le hic, c'est sue Sid n'a pas la dernière version...
 
Edit : Vous avez une manip' pour supprimer complètement Gnome proprement ?

Petite question systemD.

Contexte, j'ai une installation avec un /boot en ext4 non chiffré et tout le / chiffré en LVM. (pas sûr que ça soit l'explication du pb mais je précise des fois que...)

J'ai un pgm que je démarre sous forme de service systemd.
ce pgm est installé dans /opt.
Sous openSuse, je n'avais aucun problème, mon pgm démarrait toujours à 100%.
Sous debian, je ne sais pas si c'est l'ordre de démarrage des services qui change ou les dépendances mais il arrive très souvent qu'il ne démarre pas ou quand il veut.

J'ai modifié le démarrage, pour que ça soit un timer qui démarre 40s après le démarrage histoire d'être sûr qu'il démarre bien après le reste mais ça ne change rien, parfois ça marche parfois pas.
JE n'ai aucune erreur remonté par mon pgm, le service systemD lancé par le timer est bien "actif" mais les logs du pgm ne sont pas là.
Sachant que le pgm commence par remonter des logs sur la lecture de son fichier de conf, s'il se lançait je devrais avoir au moins ça, mais là non rien.

J'ai donc le service timer:

Et le service du pgm:

Y a des trucs mieux que ça à faire?
Pour rappel, ça marche quand même souvent, mais parfois pas (genre sur ce boot c'est ok, alors que hier c'était ko 2 fois d'affilé... )

EDIT: j'ai cherché comment le faire démarrer en dernier histoier d'être sûr que ça parte bien après tous les autres services des fois que ça soit un truc qui manque mais non ça ne veut pas.
Limite si ça démarre à l'ouverture de session utilisateur ça serait good, mais là non plus pas trouvé vu que ça doit démarrer en root.

J'ai essayé le WantedBy=multi-user.target, c'est ce qui marchait chez openSuse et que j'avais avant du coup, mais justement ça coinçait comme si ça démarrait trop vite.

1e chose à faire: regarder dans les logs ce qui s'est passé
surtout à la fin d'un boot ou tons service ne s'est pas lancé

merci, pour l'info, c'est vrais que j'ai zappé de regarder là, mais je pense que ce qu'on voit de remonté dans systemclt status mon_service c'est la même chose.
Hors je n'ai aucune remontée de log du pgm.

J'ai regardé comment tuxedo lançait son service sous debian, et ça semble ultra "simple", un peu comme j'avais fais sous OpenSuse au final, du coup, je ne comprends pas pourquoi pour moi ça ne marche pas.
Je vais réessayer pour voir.

EDIT: c'est ça je confirme je voyais la même chose.
Les fois ou ça ne marche pas j'avais ça:

ça correspondait à une section Unit du service que j'ai enlevé hier soir à savoir ça.

Mais ça ne me semble pas logique que ça soit réellement l'origine du pb vu que les autres fois ça marche sans soucis sans remonter cette erreur.
Et derrière je n'ai strictement aucun log.

Bon, je confirme ce que j'évoquais, j'ai l'impression que c'est si je reste trop longtemps sur l'écran du password pour déverrouiller le volume lvm que du coup ça ne marche pas.

J'ai rebooté, j'ai volontairement patienté sur l'écran du mot de passe, puis j'ai continué.
Dans les logs je n'ai aucune remonté d'information du démarrage du service.

Si je fais journaltcl, les dernières lignes sont l'arret du service:

Aucune trace d'information supplémentaire, alors je devrais avoir au minimum qui est propre à systemd:

DOnc je n'ai aucune information de pourquoi il ne le lance pas.

Edit, j'ai essayé de rajouter multi-user.target sur le timer pour espérer qu'il démarre plus tard j'ai donc:

SI je regarde les logs du timer, il se lance bien au boot exemple:

Mais niveau log côté mon_pgm.service, il n'y a rien.

J'avoue ne pas comprendre, je peux reproduire le fonctionnement à chaque démarrage si j'attends sur la saisie du mdp du volume lvm.

EDIT2: j'ai essayé de rajouter
"RequiresMountsFor=/opt/" sur le timer, mais pareil ça ne change rien.

Au moins je sais comment reproduire le problème c'est si j'attends plus que les 40s de mon timer que le pb se pose mais je ne sais pas comment régler ça du coup...

EDIT3: j'ai testé de rajouter: After=-.mount pour lui dire de ne passer qu'après le montage de /
mais pareil ça ne change rien...

Je me demande si c'est réellement réalisable avec un timer, ce qui ne m'arrange pas.

Concernant mon histoire de DNS: Je ne veux pas crier victoire trop vite, mais depuis que j'ai désactivé le IPv6 j'ai presque plus de soucis. Je vais faire la modif pour rendre ça permanent (->grub) et observer... C'est pas une solution géniale mais bon...
 
Par contre j'ai encore un port USB (un sur deux en façade) qui semble mécaniquement HS. C'est vraiment une plaie ces trucs, j'avais juste changé le machin justement.     Oui, désolé...

Réinstaller le système sans cocher la case gnome ?

Spa comme si j'avais parlé du ipv6.disable=1 il y a quelques pages

Pas facilement, il y a du monde derrière le paquet "gnome". A voir ce que tu veux garder de ce que tu veux supprimer:

C'est bien suite à ça que j'avais testé.

Nan mais sté pour rire, je sais bien que gnome met du merdier partout

Bon, pour ceux que ça intéresserait, j'ai finalement trouvé une solution pour mon cas.
J'ai modifié mon timer pour ça au final:

Et c'est ok.
Je ne sais pas si c'est le fait d'avoir rajouté wants, ou le fait d'avoir enlevé le mode persistant mais tout est ok pour l'instant à chaque boot.
Que je tappe le plus rapidement possible mon code, ou que j'attende 2 minutes le service est bien fonctionnel.

J'ai eu plusieurs fois des loleries bien aléatoires avec l'IPV6 du coup je ne cherche même plus, c'est dégagé d'office. Surtout qu'au boulot c'est un gros réseau d'université où l'IPV6 est distribuée par les switch et j'ai l'impression que pour des raisons X ou Y, ta machine décide de prendre l'IPV6 en priorité sans trop savoir pourquoi et ça fait chier tout le monde. Du coup, c'est loin, surtout que je n'en ai pas besoin.

Y a un truc qui me les brise un peu sur certaines machines uniquement, lors d'updates de packages, il y a un process
 

 
qui attend comme un con pendant des lustres quand le service redémarre . Et sur certaines machines gens une tinkerboard qui tourne un debian arrangé, je suis obligé de kill le service sinon ça attend indéfiniment.
 

Pour mon histoire de DNS, je voulais mettre en place la désactivation(?) du IPv6 mais au final le soucis semble parti tout seul?!?! En tout cas j'ai rien modifié au niveau GRUB au final et depuis hier pas (ou presque pas) de délai quand j'ouvre une page. Allez comprendre...  

parce que le problème n'est pas chez toi.

ah ben tant mieux.

J'ai un vieux NAS Netgear qui tourne sous une base Debian.

Ça se tente un upgrade système selon vous ? J'aimerais installer un petit script qui envois des mails avec des tests SMART à intervalle régulier.

Le système (Jessie) :

Il n'est plus possible de faire des apt update :

Essaie de faire comme indiqué là :
 
Using Old Debian Versions In Your sources.list
 

 
Je pressens le code proprio qui va avoir des dépendances non satisfaites sur une version de Debian récente, cela dit je suis curieux de voir ce que ça va donner

Je crains aussi, sinon j'aurais déjà tenté l'upgrade
 
J'ai backupé les DATA, je vais pouvoir tenter le truc à la Hussarde.

Des tests SMART ou simplement l'état SMART que renvoye smartctl? Ce dernier faut surtout pas s'y fier, faut regarder les détails! Perso je regarde notamment le nombre de secteurs réalloués, si il passe à autre chose que 0 c'est échange voir DEEE. Bon après un NAS qui a un RAID c'est moins critique que sur un seul disque...
 
Mais rappellons quand même que le RAID ne remplace pas les backup.

Bon, c'est à moitié migré sous stretch, et c'est pété !
 

Ben des-hold les

Ah oui tient, on peut un-hold au lieu de remove, ce qui est bien vu que je suis connecté via ssh

Bon, je continue avec des problèmes de dépendances, je sens que ça va être long.

Optimiste, le dist-upgrade jessie->bookworm ...

Je suis passé par Strech avant
 
Et je me suis un peu emballé

Effectivement    perso je fais toutes les version dans ce genre de cas. Regarde aussi qu'il n'y ai pas une conf à la con dans apt qui bloque les packages en version locales uniquement, j'ai eu ça sur le debian pourri d'une Asus tinkerboard, apt upgrade me disait qu'il n'y avait rien à mettre à jour alors que si. Le truc avait mis une priorité 999 aux sources locales.

Déjà fait, j'avais une prio 600 sur les sources Netgear.
 
Là on dirait plus une dépendance à la con non satisfaite.