Yeni Terminal sekmesi yükleme süresini nasıl hızlandırabilirim?


93

Lion'da terminal başlangıcını nasıl hızlandırabilirim?

Terminal uygulamasının başlangıcına değil, yeni bir sekme açtığımda olduğu gibi başlangıç ​​terminal pencerelerine atıfta bulunuyorum.

.Bash_profile dosyamda hiçbir şey yok ve rm -rf /private/var/log/asl/*.aslher 4 saatte bir çalışıyorum (bu genellikle terminali yavaşlatan dosyaları siler).

Şu anda, yeni bir sekme açtığımda, bir şeyi çalıştırabilmem 3-4 saniye sürüyor.


2
Belki de sisteminizde yanlış olan bir şeyler var? O kadar yavaş olmamalı. Bazen benim için bir ya da iki saniye sürer, ancak genellikle sadece iki saniyedir. Ve benim de ortada biraz ısırdım .bash_profile( ~/.profilebu arada kontrol et ). Ayrıca: bash yüklenirken yazmaya başlayabileceğinizi ve genellikle yazdıklarınızın hazır olduklarında komut istemine kopyalanacağını unutmayın.
Abhi Beckert

Bir ağ hesabı mı yoksa bir ağ giriş dizini mi kullanıyorsunuz? Terminali oluştururken Terminal kullanıcı girişine cevap veriyor mu? Dönen meşgul imleci görüntülüyor mu?
Chris Page

1
Terminal'in zamanı nerede geçirdiğini bulmak için, Aktivite İzleyicisi'ni açın, Terminal'i seçin ve Örnek İşlem araç çubuğu düğmesini tıklayın, ardından hemen Terminal'e gidin ve yeni bir pencere / sekme oluşturun. Örnek, zamanın nereye gittiğine dair bir ipucu sağlayabilir. Ayrıca, İşlem İzleyicisi'ndeki işlem listesini izleyin: Gecikme sırasında listede "login" veya "bash" (veya hangi kabuğu kullanıyorsanız) görünürse, bu gecikme muhtemelen bu iki programdan birinde gerçekleşiyor demektir. Terminal.
Chris Page

PATH değişkeninizi kontrol ettiniz mi? Bazı kafa karıştırıcı .bashrc olayları nedeniyle benimkinin çok uzun sürdüğünü ve çok uzun sürdüğünü fark ettim. Tekrarları kaldırdım ve her şey hızlandı!
190290000 Ruble Adam

Yanıtlar:


93

Kısa cevap:

Sorun, (potansiyel olarak) pahalı bir ASL sistem günlüğü aramasından kaynaklanır. Bunu çalışırken görmek sudo fs_usage | grep 'asl.*login'için Terminal penceresinde çalıştırın , sonra yeni bir Terminal penceresi açın.

Sorunu çözmek için, Terminal'i standart olmayan bir kabuk açacak şekilde yapılandırın:

  1. Tercih ettiğiniz kabuğa bir bağlantı oluşturun. Örneğin:sudo ln -s /bin/bash /usr/local/bin/bash
  2. Terminal Tercihleri'ni açın ve "Genel" sekmesini seçin.
  3. "Birlikte açılacak kabuklar: Komut" u seçin ve 1. adımda oluşturduğunuz bağlantıyı girin. Örneğin, "/ usr / local / bin / bash".

1 Not: Ayrıca eklemek gerekebilir bashve -bash"Terminal Tercihler> Profiller> Shell> kapatmadan önce sor" proses listeye.

Not 2: /usr/local/binOS X 10.11 (El Capitan) Rootless modunda yazılabilir.

Düzeltmeyi doğrulamak için:

  • Yeni bir Terminal penceresi açın.
  • "Son Giriş:" gerektiğini değil üst kısmında görüntülenir
  • Müfettişi açın (Command + I) ve Bilgi sekmesini seçin.
  • Komut okumalısınız login -pfq username /usr/bin/bashveyalogin -pfql username ...

Önemli: Oturum açma komutu -qparametreyi içermiyorsa , sorunu çözmediniz.

Yeni bir Terminal penceresi açarken erişilmediğini sudo fs_usage | grep 'asl.*login'doğrulamak için de kullanabilirsiniz /var/log/asl.

Detaylar:

Burada oyunda çok sayıda böcek var.

Yavaşlığın asıl nedeni, /usr/bin/loginvarsayılan olarak son giriş bilgilerinizin tarihini görüntüleyecek olandır. Bu son giriş tarihini almak için adresindeki ASL (Apple Sistem Günlüğü) veritabanında arama yapar /var/log/asl/. Bu günlük dosyaları çok ağır parçalanabilir ve yeni bir pencere veya sekme açarken gecikmeye neden olan bu dosya parçalanmasıdır. (Hata 1)

Son giriş için ASL aramasını gizlemenin tek yolu -qparametreyi iletmektir /usr/bin/login. .hushloginDosyası da "Son Giriş" görüntülenmesini engelleyebilir, ancak pahalı ASL arama bastırmak etmez. (Hata 2)

Terminal /usr/bin/loginher yeni pencere / kabuk başlatmak için her zaman kullanır . Doğrudan bir kabuk fırlatma seçeneği yoktur ve doğrudan iletilen parametreleri doğrudan kontrol etmenin bir yolu yoktur /usr/bin/login(Hata 3).

Görünen o ki, Terminal standart olmayan bir kabuk kullanacak şekilde yapılandırıldığında -qparametreye geçecektir . (Hata 4)/usr/bin/login

-qParametre biz sorunu önlemek için dolayısıyla sembolik gerekenler /usr/local/bin/bash.


6
Komutun / bin / bash ile bir bağlantısı olduğunda neden -q'nin eklendiğini biliyor musunuz / eğer / bin / bash değilse?
Lri

3
@LauriRanta 10.7 ve 10.8 Terminalinde bir hata gibi görünüyor. Start komutu ayarlandığında /bin/bash, Default Login Shell seçilmiş gibi davranır. Bunun dışında herhangi bir komut /bin/bashdüzgün çalışacaktır, bu nedenle / usr / bin / bash komutunu kullanmak yalnızca geçici bir çözümdür. Bu hata Snow Leopard'da mevcut değil.
Darren

5
@Darren, bu şüpheli hatayı Apple'a bildirdin mi? Değilse, içinden yüzden yapabileceği edin: bugreport.apple.com
Graham Miln

3
Maalesef, bu Yosemite'deki terminali her kapatışınızda koşarken koşma ile ilgili bir provayla sonuçlanıyor. Yani güzel bir düzeltme :(
Claus Jørgensen

2
@ ClausJørgensen Bu sorunu yaşamamıştım. Profiller sekmesinin altındaki "Kabuk" ayarlarını kontrol etmek isteyebilirsiniz.
Darren

20

İhtiyacım olan şey, giriş kabuğundan /bin/bash -il iTerm'in Tercihler> Profiller> Genel> Komut'taki komuta geçmek oldu .

Çevresel değişkenleri ayarlamak için eklenmiş seçeneğe ihtiyacım vardı -l( sanki bir giriş kabuğu gibi çağrılmış gibi davran )~/.bash_profile


Bu ASL giriş sorusunu kabul edilen soruya göre
durdurur

4
Tüm çözümlerin dışında, bu benim için çalıştı. 50!
Bhavin Doshi,

1
Bu iş parçacığı etrafında harika bilgiler! Bu benim kullandığım çözüm, çünkü sembolik bağlantılar veya başka şeyler oluşturmayı gerektirmiyordu. Yeni kabuk başlatma sürelerim bu çözümle ~ 5-10 saniye arasında bir an önce geçti.
DustinB

16

.hushlogin

Ana klasörünüzde boş bir dosya oluşturun .hushlogin; Bu, bir Terminal.app sekmesinin görünmesi için gereken süreyi önemli ölçüde azaltır.

.hushloginAşağıdaki komutu kullanarak dosyayı Terminal.app içinde oluşturabilirsiniz :

touch ~/.hushlogin

Dosya derhal yürürlüğe girecek.

Giriş kılavuzunda.hushlogin genel olarak dosya ve giriş işlemi hakkında daha fazla bilgi edinebilirsiniz .

Giriş işlemini susturma

Yeni bir Terminal sekmesi oluşturduğunuzda, giriş işleminden geçersiniz. İşlem, önceki oturum açma oturumunuz, günün mesajı ve sistem mesajlarının görüntülenmesi hakkında çeşitli bilgiler edinmeyi içerir. Bu önemli gecikmelerin kaynağı olabilir. Gecikmenin kaybolup kaybolmadığını görmek için bu mesajları susturmayı deneyin.


6
.hushlogin aslında sorunu çözmüyor. Bu kullanılarak onaylanabilir opensnoop. Aşağıdaki cevaba bakınız.
Darren

1
@Darrren: man login bana şunu söylüyor: -q Bu sanki bir .hushlogin varmış gibi sessiz girişleri zorlar. Q seçeneği söyledikleriniz sorunu önler, ancak sadece hushlogin ile aynı şeyi yapar.
Christian,

8

Tamam, Darren'e benzer bir sonuca vardım, ancak biraz farklı profil oluşturma mekanizması (NB yavaş giriş hala Yosemite'de gerçekleşebilir).

OS X sample profiler komutunu kullanarak yeni bir giriş penceresi başlattığınızda gerçekte neyin çalıştığını anlamanın bir yolu .

Normal bir girişin hangi komutu çalıştırdığını öğrenin

$ ps -ef | grep login

Gibi bir şey göreceksiniz login -pfl username /bin/bash -c exec -la bash /bin/bash

profile_login.shEkleyerek, aşağıdaki içeriğe sahip bir komut dosyası adı oluşturun.

-c ""

Bu bashın derhal geri dönmesini istemek için keşfedilen komutun sonuna;

login -pfl username /bin/bash -c exec -la bash /bin/bash -c "" &
sudo sample $! -mayDie # sample the above command

Çalıştırılabilir yap

$ chmod u+x profile_login.sh

ve sudo kullanarak çalıştırın ( samplekomut gerektirir)

$ sudo ./profile_login.sh

Tamam öyleyse devam et ve koş. Örneğin, purgeilk önce komutu çalıştırarak . Kutumda büyük bir çıktı grafiği var. "En büyük numaralı şubeleri" arıyorum (genellikle en üstte) Aşağıdaki iki en büyük suçluyu gördüm :

pam_startPam auth lib görüntülerini açıyor gibi görünen bir şeyden biri

+   ! 1068 pam_start  (in libpam.2.dylib) + 132  [0x7fff97295ab0]
+   !    :   1066 openpam_dynamic  (in libpam.2.dylib) + 120  [0x7fff97293d14]
+   !    :   |   +   !   1042 coresymbolication_load_image(CSCppDyldSharedMemoryPage*, ImageLoader const*, unsigned long long)  (in dyld) + 143  [0x7fff66725411]
+   !    :   |   +   !   :     1042 mach_msg_trap  (in dyld) + 10  [0x7fff6674a472]

ve bunu bazen başka bir suçlu izliyor getlastlogxbyname

+   ! 583 getlastlogxbyname  (in libsystem_c.dylib) + 212  [0x7fff92b3ef7a]
+   !       : 566 asl_file_open_read  (in libsystem_asl.dylib) + 143  [0x7fff8c27030d]
+   !       : | 566 __open_nocancel  (in libsystem_kernel.dylib) + 10  [0x7fff97b39012]    +   !       : | 566 __open_nocancel  (in libsystem_kernel.dylib) + 10  [0x7fff97b39012]

Yani temelde, iki suçlu var. Biri pam(bir tür kimlik doğrulama sistemi) diğeri ise asl"en son giriş bilgilerinizi algıla" öğesidir. Yani görünüşe göre sadece/private/var/log/asl/*.asl dosyalarınızı silmek yeterli değildir. Pam yükleme zaten makinemde çok daha pahalı, [SSD]. Yukarıdaki betiği çalıştırmaktan çekinmeyin ve sisteminizin aynı olup olmadığını görün. İlginç bir şekilde, bu yöntem çağrıları için kaynak kodunun çevrimiçi olarak da erişilebilir olduğu görülüyor, örneğin openpam_dynamic

Darren'ın cevabını takip edip "açık mermi açık" yerine / bin / bash dışındaki bir şeyi tercih edersem, yeni terminal sekmeleri başlatmak için kullanılan aşağıdaki satırları görürüm:

 $ ps -ef | grep login
  ... login -pfql packrd /bin/bash -c exec -la bash /usr/bin/bash

Öyleyse şimdi sampleyeni giriş komutunda aynı numarayı kullanırsam

login -pfql username /bin/bash -c exec -la bash /usr/bin/bash -c "" &
sudo sample $! -mayDie

çok daha küçük bir istif üretildi, en büyük suçlu şu:

+         8 pam_end  (in libpam.2.dylib) + 190  [0x7fff97294ebb]
+             !           6 coresymbolication_unload_image(CSCppDyldSharedMemoryPage*, ImageLoader const*)  (in dyld) + 143  [0x7fff6e0f634f]

Bunun nedeni "-q" girişinin şimdi kullanılmakta olduğudur. Görünüşe göre bu parametre hem Pam modüllerini yüklemek atlar ve son giriş zamanı (her iki suçluların) aranırken. loginKomutun belgelerine göre , ~/.hushlogindosyaya dokunmak aynı şeyi yapmalı, ancak görünüşe göre bu artık işe yaramıyor [en azından benim için 10.10 ile].

Bu yüzden, özet olarak, /private/var/log/asl/*.asl adresinin kaldırılması yeterli değil (denememde, yalnızca gerçek yavaşlamanın en fazla 1 / 3'ünü oluşturuyordu. daha büyük bir yüzde için eminim).

Her neyse, benzer komut dosyalarını kullanarak, yerel makinenizin ne hızlanmasına neden olduğunu söyleyebilmeli ve yukarıdaki düzeltmenin sizin için geçerli olup olmadığını görebilmelisiniz. Burada yorum yapmaktan çekinmeyin.

GÜNCELLEME: çağrıldığında coresymbolication_load_imagebile tonlarca zaman alabilir gibi görünüyor login -pfql(muhtemelen bazı pam kimlik doğrulama modülleri veya diğerlerinin merkezi bir giriş sunucusuna veya bazı gariplere "çevirmesi gerekiyor", bu nedenle 3. bir tarafın yanıtını beklemesi gerekiyor. ). Böylece bulduğum tek gerçek geçici çözüm iTerm2'yi kullanmak ve tercihlerini -> profiller -> genel -> Komut olarak değiştirmekti /bin/bash.


1
ASL araması dışında, oturum açmadaki gecikmeler çoğunlukla, kullanıcı bilgileriniz istendiğinde yavaş yanıt veren bir dizin sunucusuyla bir ağda olmanızdan kaynaklanır. Dizin servislerinin etkin olduğu bir ağda değilseniz, genel sistem tıkanıklığı dışında (CPU kullanımı, bellek basıncı, G / Ç tıkanıklığı) başka önemli sürelerin ne olacağını bilmiyorum.
Chris Page

@ChrisPage Evet, muhtemelen bazı ağ dizini servisleri bir şey veya başka, iyi bir ipucu.
rogerdpack 20:15

3

Hepsi sebebi araştırmakla ilgili. İşlem başladığında kabuğun başlatılması işlemini basacak bash -xolanı girerek ne yapıldığını görebilirsiniz .

Şahsen, yalnızca uygulamanın etkinleştirilmesi ve devre dışı bırakılması arasındaki gecikmeyi ve bir etkinlik süresinden sonra oluşturulan ilk sekmede fark ediyorum. Her zaman etrafımda dolaşan bellek sayfalarıyla ilgili olduğunu düşündürüyor.


2

Tarihinizi 4 ile 10 bin satır arasında bir şeye düşürün ve belki de kaydedilmiş tüm pencereleri bırakmayı ve atmayı deneyin. Her ikisinin de yavaş makinelerde bir fark yarattığını gördüm - özellikle de depolama için SSD olmayanları.


2

Benim durumumda, yukarıdaki çalışma makinemde başarılı olmadan denedikten sonra , suçluluğun Active Directory olduğunu gördüm. Düzeltme, Directory Utility'ye gidip "Hizmet girişinde mobil hesap oluştur" özelliğini etkinleştirmek için AD servis ayarlarını düzenlemekti ("Active Directory" üzerine çift tıklayın):

Active Directory ayarları açık olan Directory Utility uygulamasının ekran görüntüsü

Bu, görünüşte AD kimlik bilgilerinin yerel olarak önbelleğe alınmasına neden olur, böylece sistem şifrenizi her doğrulamaya çalıştığında artık sunucuya çıkmak zorunda kalmaz.

Dizin Yardımcı Programına Spotlight ile veya Sistem Tercihleri ​​/ Kullanıcılar ve Gruplar'ın "Giriş Seçenekleri" bölümünden ulaşabilirsiniz ("Ağ Hesabı Sunucusu" nun yanındaki "Düzenle ..." düğmesini seçin):

"Giriş Seçenekleri" ve "Düzenle ..." yi gösteren Kullanıcılar ve Gruplar bölmesi


0

Sadece koş:

sudo creatbyproc.d
sudo newproc.d

ayrı terminallerde bu süre zarfında ne yapıldığını görmek için yeni açmayı açın.

Belirgin bir şey yoksa, aşağıdakileri deneyin:

sudo dtruss -an Terminal

Bu, sekme yükleme süresinde olan tüm ayrıntılarınızı yazdırır.


0

/etc/profileSatırı aç ve ekle, PATH=""böylece şöyle görün:

if [ -x /usr/libexec/path_helper ]; then
    PATH=""
    eval `/usr/libexec/path_helper -s`
fi

0

Benim için sorun, aktif dizin etki alanı sunucusunun geçersiz olmasıydı.

Mac'in yeniden başlatılması ve ardından yeniden başlatılması sorunu düzeltti.

görüntü tanımını buraya girin

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.