OK Mam podobny wniosek do Darrena, choć nieco inny mechanizm profilowania (w Yosemite nadal może wystąpić powolne logowanie).
Oto sposób, aby powiedzieć, co faktycznie działa po uruchomieniu nowego okna logowania, za pomocą przykładowego polecenia profilera w OS X.
Dowiedz się, jakie polecenie wykonuje normalne logowanie
$ ps -ef | grep login
Zobaczysz coś takiego login -pfl username /bin/bash -c exec -la bash /bin/bash
Utwórz nazwę pliku skryptu profile_login.sh
o następującej treści, dodając
-c ""
na końcu odkrytego polecenia, aby zażądać natychmiastowego powrotu bash, z treściami takimi jak to:
login -pfl username /bin/bash -c exec -la bash /bin/bash -c "" &
sudo sample $! -mayDie # sample the above command
Zrób to
$ chmod u+x profile_login.sh
i uruchom go używając sudo ( sample
polecenie tego wymaga)
$ sudo ./profile_login.sh
OK, więc idź i uruchom. Na przykład purge
najpierw wykonując polecenie. Na moim pudełku mam duży wykres wyjściowy. Szukając „najliczniejszych gałęzi” (zazwyczaj na górze) widziałem dwóch największych przestępców :
Jeden z czegoś, co nazywa pam_start
się otwieraniem obrazów pam auth lib
+ ! 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]
a czasem pojawia się inny przestępca 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]
Zasadniczo są więc dwaj przestępcy. Jednym z nich jest pam
(pewien rodzaj systemu uwierzytelniania), a drugim jest to asl
„wykryj swój najnowszy login”. Więc najwyraźniej samo usunięcie /private/var/log/asl/*.asl
plików nie wystarczy. W każdym razie ładowanie pam jest znacznie droższe na moim komputerze [SSD]. Uruchom powyższy skrypt i sprawdź, czy Twój system jest taki sam. Co ciekawe, kod źródłowy tych wywołań metod wydaje się być dostępny również online, na przykład openpam_dynamic
Jeśli podążę za odpowiedzią Darrena i zastąpię moje „otwarte powłoki” preferencją inną niż / bin / bash, wtedy zobaczę następujące wiersze użyte do uruchomienia nowych kart terminalu:
$ ps -ef | grep login
... login -pfql packrd /bin/bash -c exec -la bash /usr/bin/bash
Więc jeśli teraz użyję tej samej sample
sztuczki w nowym poleceniu logowania
login -pfql username /bin/bash -c exec -la bash /usr/bin/bash -c "" &
sudo sample $! -mayDie
generowany jest znacznie mniejszy ślad stosu, przy czym największym przestępcą jest:
+ 8 pam_end (in libpam.2.dylib) + 190 [0x7fff97294ebb]
+ ! 6 coresymbolication_unload_image(CSCppDyldSharedMemoryPage*, ImageLoader const*) (in dyld) + 143 [0x7fff6e0f634f]
Myślę, że dzieje się tak, ponieważ teraz używany jest parametr logowania „-q”. Najwyraźniej ten parametr pomija zarówno ładowanie modułów pam, jak i wyszukiwanie czasu ostatniego logowania (obaj przestępcy). Zgodnie z dokumentacją login
polecenia, dotknięcie ~/.hushlogin
pliku powinno zrobić to samo, ale najwyraźniej to już nie działa [przynajmniej dla mnie z 10.10].
Podsumowując, usunięcie /private/var/log/asl/*.asl nie wystarcza (w moim eksperymencie stanowiło to najwyżej 1/3 faktycznego spowolnienia, chociaż gdybyś miał tam pliki obyczajów, mógłby to uwzględnić dla większego procentu jestem pewien).
W każdym razie przy użyciu podobnych skryptów powinieneś być w stanie powiedzieć, co powoduje, że twoja lokalna maszyna się zapadła i sprawdzić, czy powyższa poprawka dotyczy ciebie. Skomentuj tutaj.
AKTUALIZACJA: wydaje się, że coresymbolication_load_image
nadal może to zająć mnóstwo czasu, nawet gdy login -pfql
zostanie wywołane (prawdopodobnie jakiś moduł uwierzytelniania pam lub inny musi „wybrać numer” do centralnego serwera logowania lub jakiś dziwny, więc musi poczekać na odpowiedź od strony trzeciej ). Tak więc jedynym prawdziwym obejściem, jakie znalazłem, jest użycie iTerm2 i zmiana preferencji -> profile -> ogólne -> Polecenie na /bin/bash
.
.bash_profile
(sprawdź także~/.profile
przy okazji). Ponadto: pamiętaj, że możesz zacząć pisać podczas ładowania bash, a zwykle to, co wpisujesz, zostanie skopiowane do wiersza polecenia, gdy będzie gotowe.