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

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.

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

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 .

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.

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

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.

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.

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ął

Dla mnie działało to poprzez edycję /etc/X11/xinit/xserverrci zmianę

exec /usr/bin/X -nolisten tcp "$@"

przez

exec /usr/bin/X -s 0 dpms -nolisten tcp "$@"

Używam Raspbian „wheezy” i rozpoczynam sesję X od startx.

Źródło: http://www.raspberrypi.org/forums/viewtopic.php?f=66&t=18200

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

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

sudo setterm -powersave off