Modo de suspensión de Raspberry Pi, cómo evitarlo

Yo uso "wheezy" última versión. El dispositivo proporciona algunas funciones de servicio web y supone estar activo las 24 horas, los 7 días de la semana. Sin embargo, si no se solicitó el servidor durante un cierto período de tiempo (es difícil decir la hora exacta), el dispositivo parece ir a dormir (con suerte no se bloqueará). El dispositivo se conectó a la red mediante un dongle wi-fi. Encontré algunas respuestas aquí que una razón del congelamiento del dispositivo puede ser que la tarjeta wi-fi está funcionando en modo económico, así que seguí las instrucciones y puedo confirmar que el dongle no se duerme, pero comienza a parpadear como si no recibiera asistencia. computadora. significa que el dispositivo aún se duerme aunque el wifi esté activado. La solución como comprar otra frambuesa pi y hacer que todo el tiempo haga ping a dormir no funciona, ya que solo ser un servidor que recibe solicitudes evita que el dispositivo se quede dormido. Intentar sondear algo desde el dispositivo no evita pasar al modo de suspensión. Realmente no puedo confirmar que ese dispositivo se vaya a dormir. No tengo un monitor o teclado conectado, e intento adjuntar algo al reiniciar el dispositivo. Por lo tanto, actualmente no tengo pistas sobre qué puede generar el comportamiento. Y sí, apliqué todos los remedios para evitar bloqueos del sistema operativo como sin turbo y aumenté el tamaño mínimo de memoria de VM.

Utilicé pasos simples y funcionó perfectamente para mí:

1. Abra una terminal raíz en Raspberry Pi. Ahora necesita editar su script que está comenzando X. En la compilación predeterminada con lightdm.

2. Abra el archivo "lightdm.conf" ubicado en,

   /etc/lightdm/lightdm.conf

3. Agregue la línea siguiente en la sección SeatDefault(o Seat:*en las versiones más recientes de LightDM)

   [Valores predeterminados del asiento]

   xserver-command = X -s 0 -dpms

4. Reinicia tu Raspberry Pi.

Ahora el problema debe resolverse.

Enlace de origen: http://chamaras.blogspot.com/2013/03/how-to-deactivate-monitor-sleep-in.html

Algo está mal. El pi no tiene un "modo de suspensión".

Solo he tenido mi pi algunas semanas y no lo he dejado encendido todo el tiempo, pero tengo la intención de hacerlo y lo he dejado encendido durante algunos largos períodos. Estoy ejecutando raspbian, y tengo una aversión personal por NetworkManager, lol, por lo que está deshabilitado. Para mantener el wifi, ejecuto un script que hace ping al enrutador cada cinco segundos. Si el ping falla, mata el dhcpcd actual e intenta configurar el wifi nuevamente cada 5 segundos hasta que tenga éxito. Registra intentos, y de hecho ha estado activo durante más de 24 horas sin necesidad de volver a conectar una vez, y cuando voy a ssh, no hay problemas.

Ya ha dicho: "Intentar sondear algo desde el dispositivo no evita ir en modo de suspensión", así que mi punto aquí es que el mío obviamente no tiene este problema, por lo que algo está mal.

Dices que se va a "dormir" pero parece que realmente tienes que reiniciar. ¿Por qué crees que está durmiendo? AFAICT, el pi no puede ir a dormir, no tiene tal capacidad. Buscando en Google, parece haber cierta confusión acerca de esto por parte de personas que tienen problemas como el suyo.

Tenga en cuenta que hay un LED rojo que permanece encendido cada vez que se conecta la alimentación, ya sea que el pi esté funcionando o no. Sin embargo, el PI es ya sea arrancado y funcionando o detenido, que no tiene un sueño, espera,, etc. modo de hibernación .

Por lo tanto, su pi se ha bloqueado, se ha detenido o está en algún tipo de estado congelado erróneo. Sienta para ver si está más que ligeramente caliente, lo que indicaría que el procesador está en un ciclo de ocupado perpetuo (una razón por la que puede estar encendido pero no responde).

Supongo que una de las razones por las que crees que está durmiendo es porque un "intento de adjuntar algo genera un reinicio del dispositivo". Eso puede suceder cuando el dispositivo está completamente detenido (pruébelo); es porque algunos dispositivos causarán una breve caída de voltaje (pero vea la NOTA) cuando se conecta por primera vez, lo que equivale a desenchufar el pi y luego volver a enchufarlo, lo cual, como sabe, enchufarlo hace que se inicie. Mi dongle wifi de tamaño nano lo hará.

NOTA: En realidad, nuestro pi probablemente se fabricó desde agosto pasado, cuando los polifusibles se reemplazaron por "cortocircuitos". Sé muy poco sobre componentes electrónicos o electricidad, pero evidentemente el problema WRT para reiniciar desde dispositivos USB sigue siendo el mismo .

Sé que esta es una vieja pregunta, pero fue el primer resultado que surgió en mi búsqueda cuando tuve esencialmente el mismo problema en mi Pi Zero recién instalado.

Encontré la clave de mi respuesta en esta otra pregunta , entre otras fuentes.

Básicamente, aunque el Pi en sí mismo aparentemente no tiene un modo de suspensión, los dispositivos individuales en Linux (incluidos los adaptadores de red) sí pueden. Cuando intenté ejecutar el comando iw wlan0 get power_savecomo se mencionó anteriormente, al principio seguía recibiendo un error. Eso se solucionó actualizando el sistema operativo:

sudo apt-get update && apt-get upgrade

Luego reinicié: sudo reboot now

Después de eso, el iwcomando verificó que el modo power_save estaba activado. Entonces, lo apagué:

sudo iw wlan0 set power_save off

Desde entonces, todo está bien. Mi pantalla se apagará, pero la conexión de red permanece activa y puedo conectarme a mi Pi incluso después de haber estado inactiva durante un tiempo.

Parece que su dongle wifi comienza a parpadear como una computadora portátil en modo de espera, pero no ha confirmado que el Pi se esté apagando. Experimento el mismo problema.

He intentado esto, pero no lo he aplicado lo suficiente como para saber si resolvió mi problema específico: https://raspberrypi.stackexchange.com/a/4518/4271

Yo buscaría problemas de energía. La conexión de dispositivos que provocan que RPI se reinicie no parece estar relacionada con ningún tipo de modo de suspensión.

Como prueba rápida, haría esto: escribir una pequeña secuencia de comandos (python / would, lo que sea más útil) y hacer que envíe un correo electrónico simple "Estoy bien" y ponerlo en su crontab para ejecutar cada 30 minutos más o menos y ver cómo va.

Me pregunto si estoy experimentando algo similar. ¿Me interesaría el conjunto de chips que tiene su dongle y el controlador que está utilizando?

Tengo uno basado en el chip RT3072 que usa el controlador rt2800usb / cfg80211. Si ejecuto esto en modo maestro, es decir, un punto de acceso, o como un cliente normal a un punto de acceso / enrutador, parece que se va a dormir y tarda un tiempo en responder. Configuré mi computadora portátil para hacer ping a la pi a través del adaptador wifi a intervalos de aproximadamente 1 segundo. Confirmé que tanto en el modo maestro como en el cliente, a veces el ping expiraba ~ 5-10 segundos en el modo cliente y de 5 a 25 segundos en el modo maestro. En modo maestro, los tiempos de espera empeoraron mucho si ejecuté el AP en 'modo n' con HT y WMM habilitados en hostapd.conf. No era tan malo en 'modo g'.

Experimenté con otro dongle wifi usando el chip RTL8188SU con el controlador de etapas r8712u. Desafortunadamente, no pude ejecutar esto en modo Master, pero como cliente, era mucho más estable que el RT3072.

Con el 3072 en modo cliente, no hubo un retraso de ping típico: fueron aleatorios de 2 ms a 320 ms con un tiempo de espera ocasional. Con 8188SU, el retraso de ping típico era de 2-3 ms con un retraso ocasional de 166-200 ms, sin tiempos de espera observables. Lo que fue particularmente extraño fue que si abría una sesión ssh en el pi y configuraba el funcionamiento superior a 0.01 segundos, por lo que había una gran cantidad de carga de la CPU y una gran cantidad de tráfico wifi, el rendimiento del 3072 mejoró enormemente con tiempos de ping típicamente 2-3ms. La carga tuvo un efecto similar en el 3072 trabajando en modo Master.

No sé qué está sucediendo, pero estaría más interesado si otros usuarios pudieran tomarse el tiempo para hacer una prueba de ping similar en su pi e informar sus hallazgos junto con su configuración y controladores. Sería interesante si otros encuentran que los tiempos de respuesta pobres y aleatorios mejoran al cargar el tráfico del procesador / wifi usando top como lo hice yo, o si dicen que encuentran algo que cree algo de trabajo y tráfico tcp / ip a través del wifi.

Solo para información, tuve este problema, así que busqué una solución aquí y encontré esta pregunta.

Sin embargo, más tarde descubrí que era solo mi Pi sobrecalentado por el aspecto de las cosas. Una vez lo saqué de su estuche. El problema parece haber desaparecido.

Para mí funcionó editando /etc/X11/xinit/xserverrcy cambiando

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

por

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

Estoy usando Raspbian "wheezy" y comienzo mi sesión de X con startx.

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

Si bien estoy de acuerdo con @goldilocks acerca de que el dispositivo pi no tiene una función de suspensión, el núcleo aún puede apagar E / S específicas mientras el dispositivo está en funcionamiento. Es a través de este razonamiento que es posible que desee probar la siguiente edición en los archivos KBD y reiniciar el dispositivo:

Realice la siguiente edición en / etc / kbd / config: POWERDOWN_TIME = 0

Supongo que define dormir cuando la pantalla se apaga. Esto es lo que encontré para trabajar:

sudo setterm -powersave off