la connexion met plusieurs minutes à s'établir (auparavant c'était moins de 10 secondes environ).
Ça, c'est généralement caractéristique d'un timeout. Ton logiciel doit chercher à se connecter à un serveur tiers qui, lui, ne doit plus répondre depuis le début de la panne et il faut attendre le délai de grâce avant que le logiciel décide d'abandonner et de passer à la solution de secours, qui peut être soit un serveur secondaire, soit des informations conservées en cache.
Ça arrive également quand c'est le DNS qui ne répond plus : toutes les connexions directement basées sur les adresses des hôtes à atteindre fonctionnent mais tout ce qui utilise un nom de domaine se met à rester plusieurs minutes en attente. Et comme cela peut être transparent pour l'utilisateur ou se trouver à un niveau très bas, il peut être parfois assez difficile d'identifier la source du problème.
Ça peut enfin se produire même si le serveur ne répondait déjà plus mais retournait quand même un refus de connexion explicite. S'il se décide à faire la carpe à la place, soit parce qu'il a réellement été éteint ou mis hors ligne, soit parce qu'un firewall trop zélé a décidé de filtrer l'ICMP, ça peut aussi engendrer les mêmes effets du jour au lendemain.
le mot de passe m'est systématiquement demandé (alors que je l'avais précédemment enregistré) et même si je l'enregistre pour toujours.
Possible qu'il s'agisse de la même cause. Si le serveur n'est plus le même, le certificat ne sera plus valide non plus.
Une autre chose qu'il m'est arrivé, notamment avec Evolution : lorsque le serveur retournait un « Internal Error » lors d'une connexion, le logiciel ne comprenait pas le code d'erreur. Il retombait donc sur le comportement « Connexion Refusée » standard et côté interface utilisateur, il me redemandait mon mot de passe en boucle, et ce pour chacune des boîtes situées sur le même serveur. :-\
# Timeout
Posté par Obsidian . En réponse au message mot de passe FTP dans Thunar (suite). Évalué à 2.
Bonjour,
Ça, c'est généralement caractéristique d'un timeout. Ton logiciel doit chercher à se connecter à un serveur tiers qui, lui, ne doit plus répondre depuis le début de la panne et il faut attendre le délai de grâce avant que le logiciel décide d'abandonner et de passer à la solution de secours, qui peut être soit un serveur secondaire, soit des informations conservées en cache.
Ça arrive également quand c'est le DNS qui ne répond plus : toutes les connexions directement basées sur les adresses des hôtes à atteindre fonctionnent mais tout ce qui utilise un nom de domaine se met à rester plusieurs minutes en attente. Et comme cela peut être transparent pour l'utilisateur ou se trouver à un niveau très bas, il peut être parfois assez difficile d'identifier la source du problème.
Ça peut enfin se produire même si le serveur ne répondait déjà plus mais retournait quand même un refus de connexion explicite. S'il se décide à faire la carpe à la place, soit parce qu'il a réellement été éteint ou mis hors ligne, soit parce qu'un firewall trop zélé a décidé de filtrer l'ICMP, ça peut aussi engendrer les mêmes effets du jour au lendemain.
Possible qu'il s'agisse de la même cause. Si le serveur n'est plus le même, le certificat ne sera plus valide non plus.
Une autre chose qu'il m'est arrivé, notamment avec Evolution : lorsque le serveur retournait un « Internal Error » lors d'une connexion, le logiciel ne comprenait pas le code d'erreur. Il retombait donc sur le comportement « Connexion Refusée » standard et côté interface utilisateur, il me redemandait mon mot de passe en boucle, et ce pour chacune des boîtes situées sur le même serveur. :-\