Mode veille Raspberry Pi, comment éviter

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.

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

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 .

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é.

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

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.

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.

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

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

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

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

sudo setterm -powersave off