Terminal Mac OS X nie loguje się

Korzystam z systemu Mac OS X w wersji 10.6.3 i kiedy otwieram terminal (przy pomocy terminal.app lub iterm), po prostu zawiesza się on na procesie logowania. Próbowałem zrestartować komputer, zmieniając polecenie uruchamiania na / bin / bash i usuwając plik preferencji terminala. Wszystko bez skutku.

Możliwe, że masz błąd w pliku .bashrc ... Możesz spróbować wstawić instrukcje echa w pliku .bashrc, usunąć go lub spróbować tcsh zamiast bash, aby sprawdzić, czy to jest problem ...

Miałem podobny problem.
W moim przypadku Terminal zwlekałby z tytułem „Terminal - login - 80x24” .

Nie chciałem ponownie instalować Terminalu z dysku OS X, więc wykonałem kilka różnych procedur, a ostatecznie jedna z nich działała. Nie jestem pewien, co jest najważniejsze, ale postanowiłem podzielić się dokładnymi krokami na wypadek, gdyby ktoś uznał je za pomocne:

1. com.apple.Terminal.plistOdejdź od ~/Library/Preferences/.

Niektórzy twierdzą, że plik konfiguracji terminalu może zostać pomieszany i uniemożliwić uruchomienie aplikacji.
Przenieś ten plik w celu utworzenia kopii zapasowej, zamknij Terminal i uruchom go ponownie.

W moim przypadku zresetowanie konfiguracji zmieniło ustawienia czcionek i kolorów na domyślne, ale problem nadal występował. Jeśli tak, przejdź do kroku drugiego:

2. Spróbuj uruchomić powłokę inną niż bash

Kilka porad, jak zmienić domyślną powłokę w Terminalu /bin/zshi zrestartować Terminal, aby sprawdzić, czy problem jest specyficzny dla bash. W moim przypadku zrobienie tego nic nie zmieniło, a Terminal nadal się zawiesił login.

3. Spróbuj przenieść .bash*pliki z katalogu domowego

Przypomniałem sobie, że podczas poprzedniej sesji utworzyłem .bash_profileplik w swoim katalogu. Być może coś jest naprawdę nie tak. Jeśli nie utworzyłeś go samodzielnie, jakiś instalator mógł go utworzyć (lub edytować), zwłaszcza jeśli oprogramowanie nie jest specyficzne dla systemu Mac OS.

Niestety Finder domyślnie nie pokazuje ukrytych plików i nie zapewnia łatwego sposobu na zrobienie tego. Jednak w moim przypadku okazało się, że Automator faktycznie może pomyślnie uruchamiać polecenia bash :

Oto skrypt, którego użyłem:

cd ~

mkdir backup
for F in .bash*
do
    mv $F backup
done

To przeniósł wszystkie pliki zaczynające się.bash w moim domowym katalogu do backuppodkatalogu.

4. Uruchom ponownie

Ponowne uruchomienie aplikacji nie działało w tym momencie dla mnie, ale postanowiłem spróbować ponownie .
Po ponownym uruchomieniu terminal działał. Voilà!

Przeniesiłem zapisany z com.apple.Terminal.plistpowrotem ~/Library/Preferences/, zastępując obecny, i postanowiłem nie przywracać starego (i nieco niezbyt przydatnego).bash* plików i usuniętego backupkatalogu.

Nie wiem, czy to zbieg okoliczności, czy kombinacja konkretnych kroków, które rozwiązały problem, ale cieszę się, że Terminal znów działa, i mam nadzieję, że twój też to zrobi.

Jeśli bieżącym procesem jest tak naprawdę „logowanie”, zwykle oznacza to, że logowanie czeka na utworzenie sesji logowania, a nawet jeszcze nie próbował uruchomić powłoki. Aby to sprawdzić, zajrzyj do Monitora aktywności i sprawdź, czy widzisz powłokę uruchomioną, czy tylko proces logowania. Zauważ, że jeśli masz otwarte inne terminale, możesz zobaczyć dla nich inne procesy logowania i powłoki, więc uważaj, które procesy sprawdzasz. Proces rozwiązywania problemów jest zwykle ostatnim z najwyższym identyfikatorem procesu (PID).

Zdaję sobie sprawę, że Mark Szymański powiedział, że ponowne uruchomienie nie pomogło w jego przypadku, ale pomyślałem, że powinienem o tym wspomnieć: jeśli naprawdę utknął w „logowaniu”, najczęstszą przyczyną jest to, że uruchomiłeś „sudo”, a następnie zamknąłeś terminal podczas gdy czekało na podanie hasła. Jeśli to zrobisz, sudo czeka wiecznie na hasło, a to blokuje wszystkie logowania, dopóki nie zabijesz procesu sudo. Najprostszym sposobem rozwiązania tego problemu jest ponowne uruchomienie. Alternatywnie możesz zabić sudo z Monitora aktywności (lub z innego terminalu, jeśli zdarzy się, że masz już otwarty). Począwszy od Mac OS X Lion 10.7, sudo zauważy, kiedy terminal zniknie i przestanie czekać na hasło, więc ten problem nie powinien już występować.

Inną przyczyną opóźnień logowania jest sytuacja, gdy jesteś podłączony do sieci Open Directory, a serwer katalogów działa wolno lub nie odpowiada. Zgłoś to swojemu administratorowi sieci. Zwykle powoduje to jedynie kilka sekund opóźnienia, ale w niektórych przypadkach mogą trwać nawet kilka minut.

Problemem nie jest powłoka ani sieć. Usuń pliki * .asl:

sudo rm -rf /private/var/log/asl/*.asl

To wymaga czasu, ponieważ uruchamia nową powłokę. Ale potem znowu działa dobrze.