Następujący komunikat pojawia się prawie przy każdym wyłączaniu komputera:
A stop job is running for Session c2 of user ... (1min 30s)
Oczekuje 1min30s, a następnie kontynuuje proces zamykania. Postępuję zgodnie z tym przewodnikiem diagnozy systemowego zamykania systemu i otrzymuję plik shutdown -log.txt (nie mogę wkleić bezpośrednio dziennika, ponieważ jest on bardzo długi). Niestety nie rozumiem dziennika samodzielnie. Czy ktoś mógłby mi pomóc dowiedzieć się, co powoduje, że mój system nie zamyka się prawidłowo?
Używam Arch Linux z jądrem 4.4.5-1-ARCH
, moja systemd
wersja to 229-3
.
Dodatek 1: Za każdym razem, gdy się wylogowuję, a następnie wyłączam komputer z ekranu logowania, nie pojawia się komunikat A stop job is running...
. Wiele razy próbowałem się wylogować przed zamknięciem, więc myślę, że nie dzieje się to przypadkowo. Mam nadzieję, że te informacje mogą pomóc.
Dodatek 2: Zawsze zawiesza się sesja c2. Tak jak sugeruje @ n.st, ponownie spojrzałem na Diagnozowanie problemów z zamykaniem i zapisałem loginctl session-status c2
zamiast dmesg
, ale wtedy nie ma nic shutdown-log.txt
. Wymieniłem loginctl session-status c2
przez systemd-cgls
i dostał następujące dziennika:
Control group /:
-.slice
└─init.scope
├─ 1 /usr/lib/systemd/systemd-shutdown reboot --log-level 6 --log-target ...
├─1069 /usr/lib/systemd/systemd-shutdown reboot --log-level 6 --log-target ...
├─1071 /bin/sh /usr/lib/systemd/system-shutdown/debug.sh reboot
└─1074 systemd-cgls
Jakieś pomysły?
Uwaga: po aktualizacji do jądra 4.6.4-1-ARCH
i systemd 230-7
błąd już się nie pojawiał.
dmesg
, wklejone dane wyjściowe nie są zbyt pouczające - pokazuje, że Wi-Fi rozłącza się po naciśnięciu przycisku zamykania (3048 sekund po uruchomieniu systemu), a następnie nic, aż do upływu czasu 1m30s i system nadal się wyłącza (po 3139 sekundach).loginctl session-status c2
. Nie jestem pewien, czy nadal możesz przejść do getty podczas zamykania systemu, ale spróbuj nacisnąć Ctrl + Alt + F2, gdy pojawi się komunikat „Trwa zadanie zatrzymania…”. Jeśli to zadziała, otrzymasz monit o zalogowanie i będziesz mógł użyćloginctl
polecenia. Jeśli nie pojawi się monit o zalogowanie, wykonaj te same czynności, co w przypadkudmesg
, aleloginctl session-status c2
zamiast tego zapisz wynik . (To wszystko przy założeniu, że zawsze zawiesza się „c2”, a nie kolejna sesja za każdym razem.)/etc/sysctl.d/50-coredump.conf
z zawartością :,kernel.core_pattern=core
ref: github.com/systemd/systemd/issues/1615#issuecomment-203507283loginctl session-status c2
zamiastdmesg
.Odpowiedzi:
Rozwiązaniem tego problemu jest skrócenie tego limitu czasu
/etc/systemd/system.conf
z 90 do na przykład 10:i uruchom następującą komendę w terminalu po wprowadzeniu zmian
źródło
Ten problem może mieć wiele przyczyn, więc konkretne odpowiedzi nie działają zbyt dobrze. Wypróbuj to w celu rozwiązania problemu:
journalctl -p5
w terminalu i naciśnij,END
aby dostać się do końca dziennika systemowego (-p5
odfiltrowuje dużo śmieci)/
i wprowadź wyszukiwane hasłotimed out. Killing.
SHIFT+N
kilkakrotnieKilling process 1234 (jack_thru) with signal SIGKILL.
Jeśli jest to zawsze ta sama aplikacja, chcesz dowiedzieć się, co robi i dlaczego nie jest zatrzymywana przy wyłączaniu. W przeciwnym razie rozwiązanie problemu może być bardziej skomplikowane, ale nadal możesz uzyskać podpowiedź lub dwie.
Powodzenia! :)
źródło
Miałem ten sam problem, szukając, znalazłem post na forum reddit Arch Linux.
Oto rozwiązanie, które działa dla mnie https://www.reddit.com/r/archlinux/comments/4bawf7/a_stop_job_is_running_for_session_c2_of_user/d17th3u
Tworzę listę dla tego https://gist.github.com/dianjuar/98d02af4050dc2df8ae6f18695d44ca3
źródło
watchdog
sprzęt zresetuje system, jeśli opóźni się lub nie przejdzie innych testów. Kiedy więc upłynie limit czasu w pytaniu, watchdog zresetuje komputer. Zastanawiam się, czy system zamknąłby się bardziej czysto, gdybyśmy tylko skrócili limit czasu zgodnie z drugą odpowiedzią. Zastanawiam się także, czywatchdog
wymusiłby reset w innych niechcianych sytuacjach.Znalazłem tutaj rozwiązanie, które działało dla mnie z Debianem 9 na vbox. Miałem typowe 120 sekundowe opóźnienie po wyłączeniu lub ponownym uruchomieniu.
https://forums.kali.org/showthread.php?32498-Delay-90-seconds-on-shutdown
Rób tak, jak mówi Ironman:
Użyłem „sudo shutdown now” i opóźnienie ponownego uruchomienia już minęło. Wydaje się to zbyt proste, ale zadziałało dla mnie (i innych).
HTH
źródło
Mając podobny problem z Kali [2017.01], z naprzemiennym opóźnieniem wylogowania wyświetlanym przez:
Udało mi się usunąć jeden błąd, najpierw zatrzymując się
NetworkManager
przed wyłączeniem lub wyłączając go za pomocą:Prawdopodobnie należy to naprawić lub w inny sposób zrestartować.
Co do drugiego opóźnienia, nie udało mi się. Wygląda na to, że może być powiązany z GDM ( Gnome Display Manager )
pulseaudio
lubdbus
. Ponieważ nie byłem w stanie wyizolować problemu, jedynym sposobem było ustawienieDefaultTimeout*Sec=5s
wpisów,system.conf
jak już wspomniano w innych postach.Inne problemy, które można zbadać, pokazano w:
i:
źródło
poweroff
lub nieshutdown
możemy się zalogować, aby zobaczyć faktycznego winowajcę. Systemd musi zarejestrować dane wyjściowe z cgls, gdy wystąpi ten problem. Najlepsze, co na razie możemy zrobić, to zapisać dane wyjściowe i skonsultować je później, jeśli / kiedy zawiedzie się ponownie.systemd-cgls
Ponieważ jest to jeden z pierwszych wyników w najbardziej przyjaznej wyszukiwarce, dodam tutaj moje rozwiązanie: używam Arch Linux z Gnome desktop; aktualne jądro na dziś: 4.16.
Dostałem wiadomość
A stop job is running for Session c2 of user ... (1min 30s)
za każdym razem, gdyRemote Login
był aktywowanySettings > Sharing
iSharing
został aktywowany.Za każdym razem, gdy to wyłączałem, mój komputer ładnie się wyłączał za pomocą przycisku zamykania Gnome.
Ponieważ „zdalne logowanie” to nic innego jak SSH, zakładam, że odpowiedź not2qubit również będzie działać, ponieważ wyłączenie NetworkManager prawdopodobnie również wyłączy SSH.
źródło
Czasami może to być spowodowane przez jedną aplikację. Zapamiętanie zmian dokonanych tuż przed tym, jak to się stanie, może pomóc w ustaleniu przyczyny. Miałem ten sam problem po instalacji
skypeforlinux-stable-bin
w Arch Linux. Zamknięcie tej aplikacji przed zamknięciem rozwiązało problem (napisałem skrypt, aby zrobić to automatycznie przed zamknięciem).źródło
Miałem ten problem przez długi czas, więc pomyślałem, że podzielę się moim rozwiązaniem.
Problem polegał na tym, że Google Chrome działa w tle i nie zamyka się po wyłączeniu komputera. Najlepszym rozwiązaniem jest więc wyłączenie tej funkcji.
To rozwiązało dla mnie. Mam nadzieję, że to pomoże.
źródło