Pourquoi faut-il des dizaines de secondes pour obtenir une invite shell?

30

C'est une sorte d'occurrence régulière qu'après la connexion SSH à un serveur (ou même l'ouverture d'un terminal sur mon Mac), la bannière de connexion s'imprime immédiatement, mais il faut environ 10 secondes à une minute pour que l'invite du shell apparaisse. Après cela, les performances sont bonnes et la latence du réseau n'est pas inhabituelle.

Cela ne semble pas être une tâche difficile sur le plan informatique, gourmande en mémoire ou gourmande en E / S. Que fait-il avec tous ces milliards de cycles CPU?

ssh performance shell

— jacobbaer
source

8

ssh -v -v -vet ur_shell -xpourrait être des étapes de débogage prudentes.

— thrig

2

Y a-t-il beaucoup de lignes dans votre .bash_history?

— kasperd

2

Regardez votre .profile et les fichiers associés (désolé, vous ne savez pas quel shell vous utilisez) et supprimez temporairement pour voir si cela améliore les choses. Vous avez probablement une ou des commandes qui expirent.

— TheFiddlerWins du

3

Alternativement à la suggestion de Moby Disk, est-il toujours aussi lent si vous démarrez le shell lui-même à partir du shell? S'il est lent lors de la (re) connexion mais rapide lors du démarrage d'un deuxième shell depuis une session connectée existante, cela vous indiquera que ce n'est pas le shell lui-même qui cause la lenteur; s'il est également lent dans les deux situations, alors quelque chose que le shell fait au démarrage prend beaucoup de temps. Quoi qu'il en soit, vous en apprendrez plus sur quel aspect de "de zéro à l'invite du shell" est lent.

— un CVn du

2

Il s'agit souvent d'une authentification GSSAPI essayant de se produire (ce qui, si vous n'êtes pas un magasin Kerberos, est probablement complètement inutile). D'autres fois, ce sont des recherches inverses DNS.

— Charles Duffy

33

Beaucoup de choses pourraient se produire ici. Vous pouvez trouver la plupart des réponses dans le manuel de votre shell, mais celles-ci sont généralement incroyablement longues et obliques, alors ...

Il y a de fortes chances que votre problème se résume à l'une des choses suivantes.

Si votre profil ou bashrc contient des éléments coûteux, envisagez de les recadrer.

Si votre profil ou bashrc utilise une recherche DNS inversée (pour définir l'invite ou quelque chose), corrigez DNS ou utilisez plutôt le nom d'hôte.

Les shells ouvrent beaucoup de fichiers, entre autres, lors de l'initialisation. Si la charge du système est élevée, elle apparaîtra souvent ici.

Si la bannière est une pré-authentification, il peut également s'agir d'une authentification (pam, LDAP, etc.) qui est lente.

Mais ce n'est peut-être rien de tout cela. Une quantité surprenante de choses se produit juste avant d'afficher l'invite!

— Faucon Momot
source

1

Un autre que j'ai vu bloquer pendant un certain temps est une tentative d'authentification GSSAPI (si elle n'est pas désactivée sur le client SSH ou la configuration du serveur). L'utilisation d'un outil de traçage complet du système tel que sysdig est probablement la meilleure solution miracle disponible pour aller au fond de ce type de problème de préoccupation croisée.

— Charles Duffy

+1 Réponse complète. Ce site a un joli organigramme pour les connexions, les fichiers qu'ils exécutent / source et d'autres informations.

— Tim S.

15

+1. 99% du temps pour moi, c'est la recherche DNS inversée.

— mpontillo

@Mike: même ici - je recommanderais de commencer par celui-ci car il est facile à corriger. C'était à 100% dans mon cas.

— WoJ

22

Il attend probablement le DNS ou essaie de s'authentifier via LDAP ou autre.

Essayez d'ajouter UseDNS noà / etc / ssh / sshd_config

S'il le fait également lors des ouvertures de session locales, vérifiez si les serveurs LDAP ou DNS que vous avez configurés sont lents ou ne répondent pas.

— sCiphre
source

6

Une possibilité (couverte par d'autres réponses) est que le processus de configuration de la session SSH elle-même soit là où le temps est perdu.

Une autre alternative est que vos scripts de démarrage du shell exécutés sur la machine distante après l'établissement de la session SSH ont quelque chose qui prend beaucoup de temps (peut-être en essayant d'accéder à un montage réseau cassé). Vous pouvez déboguer cette deuxième possibilité comme suit:

Ajoutez temporairement les éléments suivants en haut de votre ~/.bash_profile:

set -x
PS4='+ $(date "+%s.%N")\011 '

Les set -xvirages sur une mise au point pour chaque commande shell exécutée. La PS4variable contrôle la façon dont ce débogage est présenté - en particulier dans ce cas, nous utilisons datepour ajouter des horodatages.

Vous pouvez ensuite analyser les horodatages de la sortie de débogage pour voir quelles commandes de vos scripts de démarrage prennent trop de temps.

— Trauma numérique
source

1

Vrai si et seulement si le problème se produit après l'ouverture de la session distante. La plupart des causes potentielles sont liées à la négociation et à l'authentification SSH.

— Charles Duffy

2

Très amélioré. :)

— Charles Duffy

3

S'il s'agit d'un serveur Ubuntu, la configuration de connexion par défaut vérifie si des packages peuvent être mis à jour à chaque exécution d'un shell de connexion. Si les listes de packages ne sont pas dans le cache disque, cela peut prendre une seconde ou deux même sur un bureau inactif rapide.

$ ssh localhost 
Welcome to Ubuntu 15.04 (GNU/Linux 3.19.0-26-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

*** System restart required ***
Last login: Sat Sep 12 01:38:38 2015 from localhost

Pour générer ce message "redémarrage requis", il devait vérifier que le noyau en cours d'exécution n'est pas le noyau par défaut actuellement installé. (c'est-à-dire qu'il y avait un noyau et que je n'ai pas encore redémarré.) Il affichera également le nombre de mises à jour de sécurité disponibles, le cas échéant.

Je pense que c'est le ralentissement majeur de la connexion à Ubuntu qui a été introduit récemment.

Sinon, votre ~/.bash_profile/ ~/.bashrcpourrait être le problème.

Avez-vous essayé de vous connecter au serveur depuis lui-même ( ssh localhost)? Ou vous connecter immédiatement une deuxième fois? (Pour voir si c'est beaucoup plus rapide lorsque les choses sont mises en cache.)

— Peter Cordes
source

2

Il s'agit dans la plupart des cas d' un délai d'expiration d'une demande DNS.

Cause: le serveur tente une recherche DNS inversée à l'aide de l'adresse IP du client et n'obtient pas de réponse. Si A se connecte à B, B essaie de convertir l'adresse IP de A en un nom.

Solution: entrez l'adresse IP et le nom du client dans le fichier d'hôtes du serveur.

Solution: faites connaître tous les hôtes au serveur DNS.

— Klaus Hartnegg
source