Ralentir le temps de chargement de bash dans cygwin
Au moment bash prend environ 2 secondes à se charger. J'ai couru bash avec -x
drapeau et je vois la sortie et il semble que le CHEMIN est chargé de nombreuses fois dans cygwin. Le plus drôle, c'est que j'utilise le même fichier dans un environnement linux, mais il fonctionne très bien, sans la recharger problème. Pourrait le suivant l'origine du problème?
if [ `uname -o` = "Cygwin" ]; then
....
fi
- Vous semblez être posé deux problèmes ici: est-bash ont un
--startuptime
, et ce qui va mal avec ça .bashrc. Vous aurez plus de chance de demander à chaque question séparément, et pour la deuxième question, en expliquant ce qui ne va pas. - Je ne pouvais pas trouver
--startuptime
option pour bash n'importe où dans la page de man et aussi sur le web. Je pense que ces questions vont de pair, alors je leur ai demandé ensemble. - Je pense que vous avez raison. J'aurais du séparer. Je vais changer ma question en conséquence.
- Je me demande si le temps peut être lent? C'est peut-être mieux
Bash loads slowly in Cygwin
? Ce n'est pas votre anglais, tout en essayant de faire une bonne question mieux encore.
Vous devez vous connecter pour publier un commentaire.
Comme vous l'avez indiqué dans votre réponse, le problème est Cygwin du bash-completion paquet. Le moyen rapide et facile solution est de désactiver bash-completion, et la bonne façon de le faire est d'utiliser Cygwin est setup.exe (télécharger de nouveau si vous avez besoin) et sélectionnez désinstaller ce paquet.
Le plus longtemps solution est de travailler à travers les fichiers dans
/etc/bash_completion.d
et désactiver ceux que vous n'avez pas besoin. Sur mon système, les plus grands coupables pour ralentir Bash temps de chargement de l' (mailman, ombre, dsniff et e2fsprogs) tous fait exactement rien, puisque les outils qu'ils ont été créés pour compléter n'étaient pas installés.Si vous renommez un fichier dans
/etc/bash_completion.d
d'avoir un.bak
extension, il va arrêter le script en cours de chargement. Après avoir désactivé tous, mais une sélection de 37 scripts sur un de mes systèmes de cette manière, j'ai coupé le temps moyen pour bash_completion à la charge de 95% (6,5 secondes à 0,3 secondes).Dans mon cas, c'était un contrôleur de domaine windows.
Je l'ai fait pour trouver le problème:
J'ai commencé avec un simple, windows
cmd.exe
et l', tapé ceci:c:\cygwin\bin\strace.exe c:\cygwin\bin\bash
Dans mon cas, j'ai remarqué une séquence suivante:
Le plus important était d'identifier les
client_request::make_request: cygserver un-available
ligne. Vous pouvez voir comment, après cela, cygwin tente d'extraire chaque groupe à partir de windows, et des temps d'exécution de devenir fou.Un rapide google a révélé qu'un
cygserver
est:https://cygwin.com/cygwin-ug-net/using-cygserver.html
La solution a été, pour exécuter le
cygserver-config
et puisnet start cygserver
pour démarrer le service Windows. Cygwin temps de démarrage a chuté de façon significative après que.1.7.34(0.285/5/3) 2015-02-04 12:12 i686
Toutes les réponses se réfèrent à des versions plus anciennes de bash_completion, et qu'ils sont sans récente
bash_completion
.Moderne bash_completion déplacé plus de l'achèvement des fichiers
/usr/share/bash-completion/completions
par défaut, vérifiez le chemin d'accès sur votre système en cours d'exécutionIl y a beaucoup de fichiers, un pour chaque commande, mais ce n'est pas un problème, car ils sont chargés à la demande de la première utilisation de l'achèvement de chaque commande. L'ancien
/etc/bash_completion.d
est toujours pris en charge pour la compatibilité, et tous les fichiers sont chargés lorsquebash_completion
commence.Utiliser ce script pour vérifier s'il ya des fichiers obsolètes gauche dans l'ancien dir.
Il imprime la liste des fichiers dans compat dir qui sont également présents dans la plus récente (sur demande) achèvements dir. Sauf si vous avez des raisons de garder certains d'entre eux, d'examen, de sauvegarde et de supprimer tous ces fichiers.
Comme un résultat, le compat dir devrait être la plupart du temps vide.
Maintenant, pour la partie la plus intéressante de vérification pourquoi
bash
de démarrage est lent.Si vous venez d'exécuter
bash
, il va commencer une non-login, interactif coque - ce un sous Cygwin source/etc/bash.bashrc
et puis~/.bashrc
. Ce plus probable ne comprend pas bash completion, à moins que vous la source de l'un des fichiers rc. Si vous exécutezbash -l
(bash --login
), démarrerCygwin Terminal
(dépend de votrecygwin.bat
), ou vous connecter via SSH, il va commencer une login, interactif shell - dont la source/etc/profile
,~/.bash_profile
, et sur ces fichiers rc. Le/etc/profile
script lui-même les sources de tous les exécutables.sh
fichiers dans/etc/profile.d
.Vous pouvez vérifier la durée de chaque fichier source. Trouver ce code dans
/etc/profile
:Le sauvegarder, puis le remplacer par ceci:
Commencer
bash
et vous verrez combien de temps chaque fichier pris. Enquêter sur les fichiers qui prennent un temps considérable. Dans mon cas, c'étaitbash_completion.sh
etfzf.sh
(fzf est floue finder, un très bon complément à bash_completion). Maintenant, le choix est de le désactiver ou de poursuivre l'enquête. Depuis que je voulais continuer à l'utiliserfzf
raccourcis dans bash, j'ai fait des, trouvé la cause de ce ralentissement, optimisé, et soumis mon patch pour fzf repo (j'espère qu'il sera accepté).Maintenant, pour le plus grand temps de spender -
bash_completion.sh
. Essentiellement que les sources de script/usr/share/bash-completion/bash_completion
. J'ai sauvegardé le fichier, puis l'a édité. Sur la dernière page, il y afor
boucle que les sources de tous les fichiers danscompat
dir -/etc/bash_completion.d
. Encore une fois, j'ai ajoutéTIMEFORMAT
ettime
, et vu le script a été l'origine de la lenteur de départ. Il a étézzz-fzf
(fzf
package). J'ai enquêté et trouvé un shell interne est exécuté ($()
) en cours d'exécution à plusieurs reprises dans unefor
boucle, réécriture de la partie, sans l'aide d'un shell interne est exécuté, faire le script de travailler rapidement. J'ai déjà soumis mon patch pour fzf repo.La plus grande raison pour laquelle tous ces ralentissements est:
fork
n'est pas pris en charge par Windows modèle de processus, Cygwin fait un excellent travail de l'émulation, mais il est terriblement lent comparé à un vrai UNIX. Un shell interne est exécuté ou un pipeline qui fait très peu de travail en elle-même passe la plupart de son temps d'exécution pourfork
-ing. E. g. comparer les temps d'exécution detime echo msg
(0.000 s sur mon Cygwin) vstime echo $(echo msg)
(0.042 s sur mon Cygwin) - le jour et la nuit. Leecho
commande elle ne prend pas de temps appréciable pour l'exécuter, mais la création d'un shell interne est exécuté est très cher. Sur mon système Linux, ces commandes 0.000 s et 0,001 s respectivement. De nombreux paquets de Cygwin a sont développés par des personnes qui utilisent Linux ou UNIX, et peut fonctionner sur Cygwin non modifiée. C'est donc naturellement que ces devs n'hésitez pas à utiliser sous-coquille, des pipelines et d'autres fonctionnalités dans la mesure du pratique, car ils ne se sentent pas significatifs de performance coup sur leur système, mais sur Cygwin ces scripts shell peuvent courir des dizaines et des centaines de fois plus lent.Bas de ligne, si un script shell fonctionne lentement dans Cygwin - essayez de localiser la source de
fork
appels et de réécrire le script pour les éliminer autant que possible.E. g.
cmd="$(printf "$1" "$2")"
(utilise une fourchette pour shell interne est exécuté) peuvent être remplacés parprintf -v cmd "$1" "$2"
.Garçon, il est vraiment long. Tout les gens encore la lecture jusqu'ici sont de vrais héros. Merci 🙂
Je sais que c'est un vieux thread, mais après une nouvelle installation de Cygwin cette semaine, je suis toujours à avoir ce problème.
Au lieu de la cueillette à la main tous les bash_completion fichiers, j'ai utilisé cette ligne pour mettre en œuvre @me_and de l'approche de tout ce qui n'est pas installé sur ma machine. Cela a considérablement réduit le temps de démarrage de bash pour moi.
Dans
/etc/bash_completion.d
, exécutez les opérations suivantes:Nouvelle réponse pour un vieux thread, relatives à la
PATH
de la question d'origine.La plupart des autres réponses traiter avec le bash de démarrage. Si vous êtes témoins d'un lent temps de chargement lorsque vous exécutez
bash -i
à l'intérieur de la coquille, ceux qui peuvent s'appliquer.Dans mon cas,
bash -i
courrais vite, mais chaque fois que j'ai ouvert un nouveau shell (que ce soit dans un terminal ou dans un xterm), il a fallu un temps très long. Sibash -l
est de prendre beaucoup de temps, cela signifie que c'est le moment de la connexion.Il y a certaines approches à la Cygwin FAQ https://cygwin.com/faq/faq.html#faq.using.startup-slow mais ils n'ont pas de travail pour moi.
L'affiche originale a demandé à propos de la
PATH
, qu'il diagnostiquée à l'aide debash -x
. J'ai aussi constaté que, bien quebash -i
a été rapide,bash -xl
a été lente et a montré beaucoup d'informations sur laPATH
.Il y avait une telle ridiculement longue Windows
PATH
que le processus de connexion conservées sur l'exécution des programmes et des recherches sur l'ensemble desPATH
pour le programme de droite.Ma solution: Modifier le Windows
PATH
pour supprimer le superflu. Je ne suis pas sûr de la pièce, je l'ai enlevé qui a fait le tour, mais la connexion de démarrage du shell est passé de 6 secondes à moins de 1 seconde.YMMV.
Ma réponse est la même que npe est au-dessus. Mais, depuis que j'ai rejoint, je ne peux pas commenter ou même upvote il! J'espère que ce post ne sont pas supprimées, car il offre le réconfort pour ceux qui cherchent une réponse à le même problème.
npe la solution a fonctionné pour moi. Il n'y a qu'une mise en garde - j'ai dû fermer tous cygwin processus avant que je sois le meilleur. Que comprend l'exécution des cygwin services, comme les sshd, et le ssh-agent que je pars de mes scripts de connexion. Avant cela, la fenêtre du terminal cygwin apparaît instantanément mais bloquer pendant plusieurs secondes avant qu'il ne présente l'invite de commandes. Et il pendu pendant plusieurs secondes après la fermeture de la fenêtre. Après j'ai tué tous les processus et a commencé à la cygserver service (btw, je préfère utiliser Cygwin moyen - 'cygrunsrv -S cygserver', que "net start cygserver"; je ne sais pas si cela fait une différence pratique) il commence immédiatement. Ainsi, grâce à des npe à nouveau!
Je suis sur un réseau d'entreprise avec une jolie installation compliquée, et il semble que vraiment tue cygwin les temps de démarrage. Liées à la npe réponse, j'ai également eu à suivre quelques étapes de la procédure décrite ici: https://cygwin.com/faq/faq.html#faq.using.startup-slow
Après l'avoir fait plus le démarrage de la cygserver mon cygwin temps de démarrage a chuté de manière significative.
Ce n'est pas vraiment un problème, parce que 2 secondes de temps de chargement sur de 2e génération i7 et SSD est en fait normal. Le coupable du plus long temps de charge que le natif de linux shell bash est
/etc/bash_completion
qui vient comme une partie de l'environnement cygwin. C'est donc cygwin problème spécifique. Je pourrais être complètement faux, mais de ce que je peux voir, chaque programme installé est installé par le programme d'installation est en cours de profilage. Plus la discussion se passe ici.Comme quelqu'un l'a mentionné ci-dessus, un problème possible est la variable d'environnement PATH contient beaucoup trop de chemin, cygwin recherche tous les d'entre eux. Je préfère directement modifier le /etc/profile, remplacer simplement la variable de CHEMIN d'accès de cygwin liées chemin d'accès, par exemple
PATH="/usr/local/bin:/usr/bin"
. Ajouter le chemin d'accès supplémentaires si vous le souhaitez.J'ai écrit une fonction Bash nommé "minimizecompletion' pour inactiver ne sont pas nécessaires à l'achèvement des scripts.
Achèvement des scripts pouvez ajouter plus d'un achèvement de la spécification ou ont achèvement des spécifications pour shell buildins, par conséquent, il ne suffit pas de comparer des noms de script avec les fichiers exécutables trouvé dans $PATH.
Ma solution est de supprimer toutes les chargés d'achèvement du cahier des charges, à la charge d'un achèvement de script et de vérifier si elle a ajouté de nouvelles spécifications d'achèvement. En fonction de cela, il est inactivé par l'ajout d' .bak pour le nom de fichier de script ou il est activé par la suppression .bak. Faire cela pour toutes les 182 scripts dans /etc/bash_completion.d résultats dans 36 active et 146 inactif achèvement de la réduction des scripts Bash heure de début de 50% (mais il devrait être clair que cela dépend sur les paquets installés).
La fonction vérifie également inactivé achèvement des scripts de sorte qu'il peut les activer quand ils sont nécessaires pour les nouveaux installé Cygwin paquets. Toutes les modifications peuvent être annulées avec l'argument -un qui active tous les scripts.
Ceci est un exemple de sortie et le temps: