Mode veille Raspberry Pi, comment éviter

32

J'utilise la dernière version de "Wheezy". L'appareil fournit certaines fonctionnalités du service Web et suppose être actif 24h / 24 et 7j / 7. Toutefois, si le serveur n'a pas été demandé pendant un certain temps (il est difficile de dire l'heure exacte), l'appareil semble aller se mettre en veille (espérons-le, il ne risque pas de tomber en panne). L'appareil connecté au réseau à l'aide d'une clé Wi-Fi. J'ai trouvé quelques réponses ici qu'une des raisons de la congélation de l'appareil peut être que la carte Wi-Fi passe en mode économie, alors j'ai suivi les instructions et je peux confirmer que le dongle ne se met pas en veille, mais il commence à clignoter comme si on n'y assistait pas ordinateur. cela signifie que l'appareil continue à dormir même si le wi-fi est activé. La solution consiste à acheter un autre pi framboise et à la rendre ininterrompue. Un seul en veille ne fonctionne pas, car le simple fait d’obtenir des requêtes sur un serveur empêche l’appareil de passer en veille. Essayer d'interroger quelque chose sur l'appareil n'empêche pas de passer en mode veille. Je ne peux pas réellement confirmer que cet appareil va s'endormir. Je n'ai pas de moniteur ou de clavier connecté, et tenter d'attacher quelque chose qui pose des problèmes de redémarrage de l'appareil. Donc, je suis actuellement à court d'indices sur ce qui peut causer le comportement. Et oui, j'ai appliqué tous les remèdes pour prévenir les pannes de système d'exploitation, car aucun turbo et une taille de mémoire minimale VM augmentée.

Don César D'Bazar
la source
y a-t-il quelque chose dans / var / log qui montre que quelque chose se passe, est en veille, le périphérique est mis hors tension?
kolin
2
Pour la postérité, s'il vous plaît noter que le matériel pi ne dispose pas d' un sommeil potentiel, suspendre, le mode etc. . Il est en cours d'exécution ou non. S'il est branché, le voyant d'alimentation sera allumé dans les deux sens.
goldilocks
Ce n'est pas juste votre dongle wi-fi. Le mien est connecté via son port Ethernet pour servir les demandes Web et il "s'endort" (ou quelque chose comme cet état) après un certain temps et ne servira plus les demandes. Si je frappe quelques touches pour le réveiller, il recommence à fonctionner. Mais c’est pénible, car la seule fois où j’ai besoin de répondre aux demandes, c’est quand je ne suis pas là pour le réveiller.
J'ai apparemment eu ce problème de pi s'endormir. Je peux arriver toutes les quelques minutes et peut durer environ 20 secondes. Cela est évident lorsque j'essaie d'accéder à un fichier via un partage Samba ou lorsque je suis SSH dans le Pi - tout s'arrête. Je pensais que c'était peut-être le Pi qui était sous charge alors j'ai couru 'top'. Il n'y avait aucune preuve de chargement lourd. Cependant, j’ai constaté que, même s’il fonctionnait avec «top», le Pi fonctionnait parfaitement. L'accès aux fichiers était facile et les connexions SSH ne subissaient aucune interruption. Donc, je ne peux pas dire ce qui cause ce problème mais ce n’est pas une lourde charge pour la CPU, bien au contraire, le Pi
Brian

Réponses:

9

J'ai utilisé des étapes simples et cela a parfaitement fonctionné pour moi:

  1. Ouvrez un terminal root dans Raspberry Pi. Vous devez maintenant modifier votre script qui démarre X. Dans la version par défaut avec lightdm.

  2. Ouvrez le fichier "lightdm.conf" situé dans,

    /etc/lightdm/lightdm.conf

  3. Ajoutez une ligne au-dessous de la section SeatDefault(ou Seat:*dans les versions plus récentes de LightDM).

    [SeatDefaults]

    xserver-command = X -s 0 -dpms

  4. Redémarrez votre Raspberry Pi.

Maintenant, le problème devrait être résolu.

Lien source: http://chamaras.blogspot.com/2013/03/how-to-deactivate-monitor-sleep-in.html

Chamara Silva
la source
1
Bienvenue sur Stack Exchange. Ici, nous nous attendons à ce que les réponses soient indépendantes, au lieu d’être simplement des liens vers des sources externes. Si vous pouvez ajouter les informations pertinentes dans votre réponse, ce sera beaucoup mieux.
Jivings
Veuillez ajouter les informations qui se trouvent sur ce site: les liens ne constituent pas des réponses acceptables.
xxmbabanexx
1
merci pour la meilleure réponse, fonctionne à merveille même en 2017
Sverre
8

Quelque chose ne va pas. Le pi n'a pas de "mode veille".

Je n'ai que quelques semaines de travail sur mon pi et je ne l'ai pas laissé depuis le début, mais j'ai l'intention de le devenir et je l'ai laissé pendant de longues périodes. Je suis sous Raspbian, et j'ai une aversion personnelle pour NetworkManager, lol, donc c'est désactivé. Pour garder le wifi, je lance un script qui envoie une requête ping au routeur toutes les cinq secondes. Si le ping échoue, le dhcpcd actuel est détruit et tente à nouveau de configurer le wifi toutes les 5 secondes jusqu'à ce qu'il réussisse. Il enregistre les tentatives, et en fait, cela fait plus de 24 heures que je n'ai plus besoin de se reconnecter une fois, et quand je vais dans ssh, pas de problème.

Vous avez déjà dit: "Essayer d'interroger quelque chose sur le périphérique n'empêche pas de passer en mode veille", donc ce que je veux dire, c'est que le mien n'a évidemment pas ce problème, alors quelque chose ne va pas.

Vous dites que ça va "dormir", mais on dirait que vous devez réellement redémarrer. Pourquoi crois-tu qu'il dort? AFAICT, le pi ne peut pas s'endormir, il n'a pas une telle capacité. En cherchant sur Google, il semble y avoir une certaine confusion à ce sujet chez des personnes qui ont des problèmes comme le vôtre.

Gardez à l'esprit qu'il y a un voyant rouge qui reste allumé à chaque mise sous tension, que le pi soit en marche ou non. Mais le pi est soit botté et en cours d' exécution ou arrêté, il ne dispose pas d' un sommeil, veille, veille prolongée, le mode etc .

Donc, votre pi s'est écrasé, s'est arrêté ou est dans une sorte d'état figé erroné. Essayez de voir s'il fait plus que légèrement chaud, ce qui indiquerait que le processeur est dans une boucle occupée perpétuelle (une des raisons pour laquelle il peut être allumé mais ne répond pas).

J'imagine que l'une des raisons pour lesquelles vous croyez qu'il est en veille est qu'une "tentative de connexion à quelque chose pose un problème pour le redémarrage de l'appareil". Cela peut arriver lorsque l'appareil est complètement arrêté (essayez-le); c'est parce que certains appareils provoquent une chute de tension brève (mais voir NOTE) lors du premier branchement, ce qui revient à débrancher le pi puis à le rebrancher - ce qui, comme vous le savez, le fait démarrer. Mon dongle wifi taille nano le fera.

NOTE: En fait, nos pi ont probablement été fabriqués depuis août dernier, lorsque les polyfuses ont été remplacés par des "shorts" - je connais très peu de choses sur les composants électroniques ou l’électricité, mais il est évident que le problème de la réinitialisation à partir de périphériques USB reste le même .

Boucles d'or
la source
6

Je sais que c’est une vieille question, mais c’est le premier résultat de ma recherche lorsque j’ai eu essentiellement le même problème sur mon Pi Zero fraîchement installé.

J'ai trouvé la clé de ma réponse sur cette autre question , parmi d'autres sources.

Donc, en gros, bien que le Pi n’ait apparemment pas de mode veille, des périphériques individuels sous Linux (y compris les adaptateurs réseau) le peuvent. Lorsque j'ai essayé d'exécuter la commande iw wlan0 get power_savementionnée ci-dessus, j'ai continué à recevoir une erreur, au début. Cela a été corrigé en mettant à jour le système d'exploitation:

sudo apt-get update && apt-get upgrade

Puis j'ai redémarré: sudo reboot now

Après cela, la iwcommande a vérifié que le mode power_save était bien activé. Alors, je l'ai éteint:

sudo iw wlan0 set power_save off

Depuis lors, tout va bien. Mon écran se mettra en veille, mais la connexion réseau restera active et je pourrai me connecter à mon Pi même après une période d'inactivité.

Dougal Campbell
la source
1
Attention, j'avais besoin d'utiliser sudo iw dev wlan0 set power_save off(le dev devait y être)
n0nag0n
Celui-ci ne fonctionne pas pour moi. Même si mon appareil wlan est nommé wlan0je reçoiscommand failed: No such device (-19)
gromit190
@ n0nag0n Je peux confirmer que l'on iwattend soit, devsoit en phytant que second argument, en fonction de la manière dont vous vous référez au périphérique sans fil. J'ajouterais également que la commande doit probablement être exécutée après chaque redémarrage.
Dmitry Grigoryev
5

On dirait que votre clé Wi-Fi commence à clignoter comme un ordinateur portable en mode veille, mais vous n'avez pas encore confirmé que le Pi était en train de s'arrêter. Je ressens le même problème.

J'ai essayé cela, mais je ne l'avais pas appliqué suffisamment longtemps pour savoir si mon problème spécifique était résolu: https://raspberrypi.stackexchange.com/a/4518/4271

Stefan Mohr
la source
1

Je vérifierais les problèmes d'alimentation. La connexion de périphériques entraînant le redémarrage de RPI ne semble liée à aucun type de mode veille.

Comme test rapide, je ferais ceci - écrivez un petit script (python / shall, ce qui est plus pratique) et faites-lui envoyer un simple courriel "Je suis bon" et mettez-le dans votre crontab pour qu'il s'exécute toutes les 30 minutes environ. voir comment ça se passe.

Abolotnov
la source
0

Je me demande si je vis quelque chose de similaire. Je serais intéressé par le jeu de puces que votre dongle a et le pilote que vous utilisez?

J'ai un basé sur la puce RT3072 en utilisant le pilote rt2800usb / cfg80211. Si je lance ceci en mode maître, c’est-à-dire un point d’accès, ou en tant que client normal d’un point d’accès / routeur, l’apparence semble s’être mise en veille et prendre un certain temps pour y répondre. J'ai configuré mon ordinateur portable pour qu'il envoie une requête ping au pi via l'adaptateur wifi à environ 1 seconde d'intervalle. J'ai confirmé qu'en temps maître et en mode client, le ping expirait parfois entre 5 et 10 secondes en mode client et entre 5 et 25 secondes en mode maître. En mode maître, les délais d'attente étaient bien pire si j'exécutais l'AP en 'n mode' avec HT et WMM activés dans hostapd.conf. Ce n'était pas si mal en mode 'g'.

J'ai expérimenté un autre dongle wifi en utilisant la puce RTL8188SU avec le pilote de transfert r8712u. Malheureusement, je ne pouvais pas le faire fonctionner en mode Maître, mais en tant que client, il était beaucoup plus stable que le RT3072.

Avec le 3072 en mode client, il n'y avait pas de délai de ping typique - ils étaient aléatoires entre 2 ms et 320 ms avec un délai d'expiration occasionnel. Avec 8188SU, le délai d’exécution du ping était généralement de 2 à 3 ms, avec un retard occasionnel de 166 à 200 ms - aucun délai d’observation n’est observé. Ce qui était particulièrement étrange, c’est que si j’ouvrais une session SSH sur le pi et que je suivais le sommet à 0,01 s - il y avait donc beaucoup de charge processeur et beaucoup de trafic wifi, les performances du 3072 étaient grandement améliorées. temps de ping typiquement 2-3ms. Le chargement a eu un effet similaire sur le 3072 fonctionnant en mode Maître.

Je ne sais pas ce qui se passe, mais je serais très intéressé si d'autres utilisateurs pouvaient prendre le temps de faire un test de ping similaire sur leur pi et de rapporter leurs résultats avec leur configuration et leurs pilotes. Il serait intéressant que d’autres trouvent que les temps de réponse aléatoires sont médiocres et qu’ils sont améliorés en chargeant le trafic processeur / wifi en utilisant top comme je l’ai fait, ou en trouvant tout ce qui crée du travail et du trafic TCP / IP via le réseau wifi.

Ivo
la source
Ce n'est pas vraiment une réponse, mais il contient un contenu suffisamment détaillé qui ne rentrerait probablement pas dans la section commentaires de la question initiale
kolin
Merci pour l'allusion kolin - Je suis nouveau sur ce forum et je n'ai pas encore tout compris!
Ivo
J'ai essayé d'implémenter Stefans answer - désactivation de la gestion de l'alimentation (pour les pilotes cfg80211 / mac80211, vous pouvez utiliser iw wlan0 set power_save off), et cela a fait une très grande différence dans le mode client - les délais de ping aléatoires sont maintenant assez stables à 2-3 ms et pas de délais d'attente pour le moment. Cela n'a pas aidé avec le mode AP (power_save off n'est pas une option avec mon appareil), mais je ne pense pas que ce soit la source du problème en mode AP car les temps de ping sont généralement stables de toute façon. Quelque chose d'autre est à l'origine des délais d'attente. Il n'est pas clair si la configuration de la question d'origine était pour le mode client ou le mode AP.
Ivo
0

Juste pour information, j'avais ce problème alors j'ai cherché une solution ici et j'ai trouvé cette question.

Cependant, plus tard, j'ai découvert que c'était juste ma surchauffe de Pi par l'apparence des choses. Une fois je l'ai sorti de son étui. Le problème semble avoir disparu

ablueman
la source
0

Pour moi cela a fonctionné en éditant /etc/X11/xinit/xserverrcet en changeant

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

par

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

J'utilise Raspbian “wheezy” et je commence ma session X avec startx.

Source: http://www.raspberrypi.org/forums/viewtopic.php?f=66&t=18200

Zengr
la source
-1

Bien que je sois d’accord avec @goldilocks sur le fait que le périphérique pi n’a pas de fonction de veille, le noyau peut toujours mettre hors tension des E / S spécifiques pendant le fonctionnement du périphérique. C'est à travers ce raisonnement que vous voudrez peut-être essayer l'édition suivante dans les fichiers KBD et redémarrer l'appareil:

Effectuez les modifications suivantes dans / etc / kbd / config: POWERDOWN_TIME = 0

hulkmeister
la source
-1

Je suppose que vous définissez le sommeil comme l'écran éteint. C'est ce que j'ai trouvé fonctionner:

sudo setterm -powersave off
Allan Cao
la source
La question indique spécifiquement "Je n'ai pas de moniteur ou de clavier connecté".
Dmitry Grigoryev
S'il est connecté au réseau, l'affiche pourrait simplement entrer. Pourquoi le vote négatif?
Allan Cao