Tryb uśpienia Raspberry Pi, jak tego uniknąć


32

Używam najnowszej wersji „wheezy”. Urządzenie zapewnia pewne funkcje usług internetowych i prawdopodobnie będzie aktywne 24/7. Jednak jeśli serwer nie był wymagany przez określony czas (trudno jest określić dokładny czas), urządzenie wydaje się spać (mam nadzieję, że się nie zawiesi). Urządzenie podłączone do sieci za pomocą klucza Wi-Fi. Znalazłem tutaj odpowiedzi, że przyczyną zamrożenia urządzenia może być to, że karta Wi-Fi przechodzi w tryb ekonomiczny, więc postępowałem zgodnie z instrukcjami i mogę potwierdzić, że klucz sprzętowy nie idzie w sen, ale zaczyna mrugać, jakby nie był obecny komputer. oznacza to, że urządzenie nadal śpi, mimo że Wi-Fi jest aktywne. Rozwiązanie polegające na zakupie kolejnego malinowego pi i sprawieniu, by pingowanie przez cały czas spało jedno, nie działa, ponieważ bycie serwerem otrzymującym żądania zapobiega uśpieniu urządzenia. Próba sondowania czegoś z urządzenia nie uniemożliwia przejścia w tryb uśpienia. Nie mogę potwierdzić, że to urządzenie przejdzie w tryb uśpienia. Nie mam podłączonego monitora ani klawiatury i próbuję załączyć coś, co powoduje ponowne uruchomienie urządzenia. Więc obecnie nie mam wskazówek, co może wydać to zachowanie. I tak, zastosowałem wszystkie środki zapobiegające awariom systemu operacyjnego, ponieważ brak turbo i zwiększenie minimalnego rozmiaru pamięci VM.


czy w plikach / var / log jest coś, co pokazuje, że coś się dzieje, idzie spać, urządzenie się wyłącza?
kolin

2
W przypadku potomków należy pamiętać, że sprzęt pi nie ma potencjalnego trybu uśpienia, zawieszenia itp . Jest albo uruchomiony, albo nie. Jeśli jest podłączony, dioda LED zasilania będzie świecić w obu kierunkach.
Złotowłosa

To nie tylko twój klucz Wi-Fi. Mam połączenie przez port Ethernet, aby obsługiwać żądania sieciowe i po pewnym czasie „zasypia” (lub coś w tym stanie zbliżonym) i nie będzie już obsługiwał żądań. Jeśli uderzę w klawisze, aby go obudzić, zacznie działać ponownie. Ale to jest ból, ponieważ potrzebuję tylko tego, aby obsłużyć żądania, kiedy nie ma mnie, aby się obudzić.

Miałem ten problem z Pi, który najwyraźniej spał. Mogę się zdarzać co kilka minut i może trwać około 20 sekund. Jest to oczywiste, gdy próbuję uzyskać dostęp do pliku za pośrednictwem udziału Samba lub gdy jestem SSHing do Pi - wszystko po prostu się zatrzymuje. Pomyślałem, że może być obciążone Pi, więc pobiegłem „na górę”. Nie było dowodów na duże obciążenie. Przekonałem się jednak, że podczas uruchamiania „góry” Pi działało idealnie. Dostęp do plików był szybki, a połączenia SSH nie uległy awarii. Nie mogę więc powiedzieć, co powoduje ten problem, ale nie jest to duże obciążenie procesora, wręcz przeciwnie, Pi
Brian

Odpowiedzi:


9

Użyłem prostych kroków i to dla mnie idealnie działało:

  1. Otwórz terminal root w Raspberry Pi. Teraz musisz edytować skrypt uruchamiający X. W domyślnej wersji z lightdm.

  2. Otwórz plik „lightdm.conf” znajdujący się w,

    /etc/lightdm/lightdm.conf

  3. Dodaj poniższy wiersz w sekcji SeatDefault(lub Seat:*w nowszych wersjach LightDM).

    [SeatDefaults]

    xserver-command = X -s 0 -dpms

  4. Uruchom ponownie Raspberry Pi.

Teraz problem powinien zostać rozwiązany.

Link do źródła: http://chamaras.blogspot.com/2013/03/how-to-deactivate-monitor-sleep-in.html


1
Witamy w Stack Exchange. Tutaj oczekujemy, że odpowiedzi będą same w sobie, a nie tylko linki do zewnętrznych źródeł. Jeśli możesz dodać odpowiednie informacje do swojej odpowiedzi, będzie znacznie lepiej.
Jivings

Dodaj informacje znajdujące się na tej stronie: linki nie są akceptowalnymi odpowiedziami.
xxmbabanexx

1
dziękuję za najlepszą odpowiedź, działa cuda nawet w 2017 roku
Sverre

8

Coś jest nie tak. Pi nie ma „trybu uśpienia”.

Miałem moje pi tylko kilka tygodni i nie zostawiłem go przez cały czas, ale zamierzam w końcu i zostawiłem to na kilka długich odcinków. Używam raspbian i osobiście nie lubię NetworkManager, lol, więc jest wyłączony. Aby utrzymać wifi, uruchamiam skrypt, który pinguje router co pięć sekund. Jeśli polecenie ping nie powiedzie się, zabija bieżący dhcpcd i próbuje ponownie skonfigurować Wi-Fi co 5 sekund, aż się powiedzie. Rejestruje próby i faktycznie działa już od ponad 24 godzin bez konieczności ponownego połączenia, a kiedy idę do ssh, nie ma problemów.

Powiedziałeś już: „Próbowanie sondowania czegoś z urządzenia nie zapobiega przejściu w tryb uśpienia”, więc chodzi mi o to, że mój oczywiście nie ma tego problemu, więc coś jest nie tak.

Mówisz, że idzie „spać”, ale brzmi to tak, jakbyś musiał zrestartować komputer. Dlaczego wierzysz, że śpi? AFAICT, pi nie może iść spać, nie ma takiej zdolności. Googlując się po, wydaje się, że istnieje pewne zamieszanie w tym zakresie od ludzi, którzy mają problemy takie jak twój.

Pamiętaj, że czerwona dioda LED świeci się za każdym razem, gdy zasilanie jest podłączone, niezależnie od tego, czy pi działa. Ale pi jest albo uruchamiany i uruchomiony, albo zatrzymany, nie ma trybu uśpienia, gotowości, hibernacji itp .

Więc twoje pi albo się zawiesiło, zatrzymało, albo jest w jakimś błędnym stanie zamrożenia. Sprawdź, czy jest więcej niż nieco ciepło, co wskazywałoby, że procesor jest w ciągłej pętli zajętości (jeden z powodów, dla których może być włączony, ale nie odpowiada).

Zgaduję, że jednym z powodów, dla których uważasz, że śpi, jest „próba dołączenia czegoś, co powoduje ponowne uruchomienie urządzenia”. Może się to zdarzyć, gdy urządzenie zostanie całkowicie zatrzymane (spróbuj); to dlatego, że niektóre urządzenia powodują krótki spadek napięcia (ale patrz UWAGA) po pierwszym podłączeniu, co oznacza odłączenie pi, a następnie ponowne podłączenie go ponownie - co, jak wiesz, podłączenie go powoduje uruchomienie. Zrobi to mój dongle Wi-Fi w rozmiarze nano.

UWAGA: W rzeczywistości nasze pi zostały prawdopodobnie wyprodukowane od ostatniego sierpnia, kiedy polyfuse zostały zastąpione przez „szorty” - wiem bardzo niewiele o komponentach elektronicznych lub elektryczności, ale najwyraźniej problem WRT przy ponownym uruchomieniu z urządzeń USB pozostaje ten sam .


6

Wiem, że to stare pytanie, ale był to pierwszy wynik, który pojawił się w moich poszukiwaniach, gdy miałem zasadniczo ten sam problem na świeżo zainstalowanym Pi Zero.

Znalazłem klucz do mojej odpowiedzi na to drugie pytanie , między innymi źródłami.

Tak więc w zasadzie, chociaż samo Pi najwyraźniej nie ma trybu uśpienia, mogą to robić pojedyncze urządzenia w Linuksie (w tym karty sieciowe). Kiedy próbowałem uruchomić polecenie, iw wlan0 get power_savejak wspomniano powyżej, na początku pojawiał się błąd. Zostało to naprawione przez aktualizację systemu operacyjnego:

sudo apt-get update && apt-get upgrade

Następnie ponownie uruchomiłem: sudo reboot now

Następnie iwpolecenie potwierdziło, że tryb power_save rzeczywiście został włączony. Wyłączyłem to:

sudo iw wlan0 set power_save off

Od tego czasu wszystko jest w porządku. Mój ekran przejdzie w tryb uśpienia, ale połączenie sieciowe pozostaje aktywne i jestem w stanie ssh do mojego Pi nawet po pewnym okresie bezczynności.


1
Heads up, musiałem użyć sudo iw dev wlan0 set power_save off(dev musiał tam być)
n0nag0n

Ten nie działa dla mnie. Mimo że moje urządzenie wlan nazywa się wlan0, otrzymujęcommand failed: No such device (-19)
gromit190

@ n0nag0n Mogę potwierdzić, że iwoczekuje jednego devlub phydrugiego argumentu, w zależności od tego, jak odwołujesz się do urządzenia bezprzewodowego. Dodam również, że polecenie prawdopodobnie musi być uruchamiane po każdym ponownym uruchomieniu.
Dmitry Grigoryev

5

Wygląda na to, że Twój klucz Wi-Fi zaczyna pulsować jak laptop w trybie gotowości, ale nie potwierdziłeś, że samo Pi się wyłącza. Mam ten sam problem.

Próbowałem tego, ale nie zastosowałem go wystarczająco długo, aby wiedzieć, czy to rozwiązało mój konkretny problem: https://raspberrypi.stackexchange.com/a/4518/4271


1

Sprawdziłbym problemy z zasilaniem. Podłączanie urządzeń powodujących ponowne uruchomienie RPI nie wygląda na związane z jakimkolwiek trybem uśpienia.

Jako szybki test zrobię to - napisz mały skrypt (python / will, cokolwiek jest wygodniejszy) i sprawię, że wyśle ​​prosty e-mail „Jestem dobry” i umieści go w twoim crontabie, aby uruchamiał się co około 30 minut i zobacz jak idzie.


0

Zastanawiam się, czy doświadczam czegoś podobnego. Byłbym zainteresowany zestawem układów twojego klucza sprzętowego i sterownikiem, którego używasz?

Mam jeden oparty na układzie RT3072 ze sterownikiem RT2800USB / CFF80211. Jeśli uruchomię to w dowolnym trybie głównym, tj. W Punkcie Dostępowym, lub jako zwykły klient Punktu Dostępowego / routera, wygląda na to, że przechodzi w tryb uśpienia i zajmuje trochę czasu, aby odpowiedzieć. Skonfigurowałem laptopa do pingowania pi przez adapter WiFi w mniej więcej 1 sekundowych odstępach. Potwierdziłem, że zarówno w trybie głównym, jak i klienckim, czasami ping wygaśnie ~ 5-10 sekund w trybie klienta i 5-25 sekund w trybie głównym. W trybie głównym limity czasu były znacznie gorsze, jeśli uruchomiłem AP w trybie „n” z włączoną HT i WMM w pliku hostapd.conf. W trybie „g” nie było tak źle.

Eksperymentowałem z innym kluczem Wi-Fi przy użyciu układu RTL8188SU ze sterownikiem przemieszczania r8712u. Niestety nie mogłem uruchomić tego w trybie Master, ale jako klient był znacznie bardziej stabilny niż RT3072.

W trybie 3072 w trybie klienta nie było typowego opóźnienia ping - były losowe od 2 ms do 320 ms z okazjonalnym czasem oczekiwania. W przypadku 8188SU typowe opóźnienie ping wynosiło 2-3 ms, a czasem opóźnienie 166–200 ms - brak zauważalnych limitów czasu. Szczególnie dziwne było to, że jeśli otworzyłem sesję ssh dla pi i ustawiłem top na 0,01 s - więc było całkiem sporo obciążenia procesora i „dużo” ruchu Wi-Fi, wydajność 3072 znacznie się poprawiła dzięki czasy pingowania zwykle 2-3ms. Ładowanie miało podobny wpływ na 3072 pracujący w trybie Master.

Nie wiem, co się dzieje, ale byłbym najbardziej zainteresowany, gdyby inni użytkownicy mogli poświęcić czas na wykonanie podobnego testu ping na swoim pi i zgłosić swoje odkrycia wraz z konfiguracją i sterownikami. Byłoby interesujące, gdyby inni stwierdzili, że czasy odpowiedzi są słabe i losowe zostały poprawione poprzez ładowanie ruchu procesora / Wi-Fi przy użyciu top tak jak ja, lub powiedzmy, znajdź coś, co tworzy trochę pracy i ruch tcp / ip przez Wi-Fi.


To nie jest tak naprawdę odpowiedź, jednak ma wystarczająco szczegółowe treści, które prawdopodobnie nie zmieściłyby się w sekcji komentarzy oryginalnego pytania
kolin

Dzięki za podpowiedź kolin - jestem nowy na tym forum i jeszcze się nie domyśliłem!
Ivo

Próbowałem zaimplementować odpowiedź Stefansa - wyłączając zarządzanie energią (dla sterowników cfg80211 / mac80211 możesz użyć iw wlan0 ustaw power_save wyłączony), i to zrobiło bardzo dużą różnicę w trybie klienta - losowe opóźnienia ping są teraz dość stałe na 2-3ms i brak limitów czasu. To nie pomogło w trybie AP (power_save off nie jest opcją w moim urządzeniu), ale nie sądzę, że jest to źródłem problemu w trybie AP, ponieważ czasy pingowania są generalnie stabilne. Przyczyną przekroczenia limitu czasu jest coś innego. Nie jest jasne, czy konfiguracja w pierwotnym pytaniu dotyczyła trybu klienta czy AP.
Ivo

0

Tylko dla informacji, miałem ten problem, więc szukałem tutaj rozwiązania i znalazłem to pytanie.

Jednak później dowiedziałem się, że to tylko moje Pi przegrzewało się z wyglądu. Kiedyś wyjąłem go ze skrzynki. Wygląda na to, że problem zniknął



-1

Chociaż zgadzam się z @goldilocks, że urządzenie pi nie ma funkcji uśpienia, jądro może nadal wyłączać określone wejścia / wyjścia podczas działania urządzenia. To z tego powodu możesz spróbować następującej edycji w plikach KBD i zrestartować urządzenie:

Dokonaj następującej edycji w / etc / kbd / config: POWERDOWN_TIME = 0


-1

Zakładam, że definiujesz spanie jako wyłączenie ekranu. Oto, co znalazłem do pracy:

sudo setterm -powersave off

Pytanie wyraźnie stwierdza „Nie mam podłączonego monitora ani klawiatury”.
Dmitry Grigoryev

Jeśli jest podłączony do sieci, plakat może po prostu ssh. Dlaczego głosować w dół?
Allan Cao
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.