Modo de suspensão do Raspberry Pi, como evitar

Eu uso o último lançamento "wheezy". O dispositivo fornece alguns recursos de serviço da web e supõe estar ativo 24/7. No entanto, se o servidor não foi solicitado por um certo período de tempo (é difícil dizer a hora exata), o dispositivo parece estar inativo (esperemos que não trava). O dispositivo conectado à rede usando o dongle wi-fi. Encontrei algumas respostas aqui que um motivo para o congelamento do dispositivo pode ser que o cartão wi-fi está entrando no modo econômico, então segui as instruções e posso confirmar que o dongle não entra no modo de suspensão, mas começa a piscar como se não fosse atendido. computador. isso significa que o dispositivo ainda dorme, embora o wi-fi esteja ativado. A solução, como comprar outro raspberry pi e fazê-lo tocar o tempo todo enquanto dorme, não funciona, pois apenas um servidor recebendo solicitações impede que o dispositivo entre no modo de suspensão. Tentar pesquisar alguma coisa no dispositivo não impede que você entre no modo de suspensão. Na verdade, não posso confirmar se o dispositivo está indo dormir. Não tenho monitor ou teclado conectado e tento anexar algo que esteja causando problemas na reinicialização do dispositivo. Portanto, atualmente estou sem pistas do que pode emitir o comportamento. E sim, apliquei todos os remédios para evitar falhas no sistema operacional sem turbo e aumentei o tamanho mínimo da memória da VM.

Eu usei etapas simples e funcionou perfeitamente para mim:

1. Abra um terminal raiz no raspberry Pi. Agora você precisa editar seu script que está iniciando o X. Na compilação padrão com o lightdm.

2. Abra o arquivo "lightdm.conf" localizado em,

   /etc/lightdm/lightdm.conf

3. Adicione a linha abaixo na seção SeatDefault(ou Seat:*nas versões mais recentes do LightDM).

   [SeatDefaults]

   xserver-command = X -s 0 -dpms

4. Reinicie o seu Raspberry Pi.

Agora, o problema deve ser resolvido.

Link da fonte: http://chamaras.blogspot.com/2013/03/how-to-deactivate-monitor-sleep-in.html

Algo está errado. O pi não possui um "modo de suspensão".

Eu só tive meu pi há algumas semanas e não o deixei o tempo todo, mas pretendo eventualmente e o deixo por alguns longos períodos. Estou executando o raspbian e tenho uma antipatia pessoal pelo NetworkManager, lol, de modo que está desativado. Para manter o Wi-Fi ativado, eu executo um script que envia um ping do roteador a cada cinco segundos. Se o ping falhar, ele mata o dhcpcd atual e tenta configurar o wifi novamente a cada 5 segundos, até que seja bem-sucedido. Ele registra tentativas e, de fato, está em funcionamento há mais de 24 horas, sem a necessidade de se reconectar uma vez e, quando vou ao ssh, não há problemas.

Você já disse: "Tentar pesquisar algo no dispositivo não impede o modo de suspensão", então o que quero dizer aqui é que o meu obviamente não tem esse problema, então algo está errado.

Você diz que vai "dormir", mas parece que você está realmente tendo que reiniciar. Por que você acredita que está dormindo? AFAICT, o pi não pode dormir, não possui essa capacidade. Pesquisando por aí, parece haver alguma confusão sobre isso de pessoas que estão tendo problemas como o seu.

Lembre-se de que existe um LED vermelho que permanece aceso sempre que a energia é conectada, independentemente de o pi estar em execução ou não. Mas o pi ou é iniciado e em execução ou interrompido, ele não tem um sono, espera, modo de hibernação, etc. .

Portanto, seu pi travou, parou ou está em algum tipo de estado congelado incorreto. Sinta-se para ver se está mais do que um pouco quente, o que indicaria que o processador está em um ciclo de atividade perpétuo (uma razão pela qual ele pode estar ativado, mas não responde).

Suponho que um dos motivos pelos quais você acredita que está dormindo é que "uma tentativa de anexar algo causa problemas na reinicialização do dispositivo". Isso pode acontecer quando o dispositivo é completamente interrompido (tente); é porque alguns dispositivos causam uma breve queda de tensão (mas consulte a NOTA) quando o conectam pela primeira vez, o que significa desconectar o pi e conectá-lo novamente - o que, como você sabe, conectá-lo faz com que ele seja inicializado. Meu dongle wifi de tamanho nano fará isso.

NOTA: Na verdade, nossos pi provavelmente foram fabricados desde agosto passado, quando os polifusores foram substituídos por "shorts" - sei muito pouco sobre componentes eletrônicos ou eletricidade, mas, evidentemente, o problema do WRT na reinicialização de dispositivos USB permanece o mesmo .

Sei que essa é uma pergunta antiga, mas foi o primeiro resultado que surgiu na minha pesquisa quando eu tinha essencialmente o mesmo problema no meu Pi Zero recém-instalado.

Encontrei a chave da minha resposta nessa outra questão , entre outras fontes.

Então, basicamente, embora o Pi em si aparentemente não tenha um modo de suspensão, dispositivos individuais no Linux (incluindo os adaptadores de rede) podem. Quando tentei executar o comando iw wlan0 get power_savecomo mencionado acima, fiquei recebendo um erro, a princípio. Isso foi corrigido com a atualização do sistema operacional:

sudo apt-get update && apt-get upgrade

Então eu reiniciei: sudo reboot now

Depois disso, o iwcomando verificou que o modo power_save estava realmente ativado. Então, eu desliguei:

sudo iw wlan0 set power_save off

Desde então, está tudo bem. Minha tela entra no modo de suspensão, mas a conexão de rede permanece ativa e sou capaz de ssh no meu Pi mesmo depois de ficar inativo por um tempo.

Parece que seu dongle wifi começa a pulsar como um laptop no modo de espera, mas você não confirmou que o Pi está sendo desligado. Estou com o mesmo problema.

Eu tentei isso, mas não o apliquei por tempo suficiente para saber se ele resolveu meu problema específico: https://raspberrypi.stackexchange.com/a/4518/4271

Eu verificaria se havia problemas de energia. A conexão de dispositivos que causam a reinicialização do RPI não parece relacionada a nenhum tipo de modo de suspensão.

Como um teste rápido, eu faria isso - escreva um pequeno script (python / will, o que for mais útil) e faça com que ele envie um e-mail simples "Eu sou bom" e o coloque no seu crontab para executar a cada 30 minutos ou mais e veja como vai.

Gostaria de saber se estou experimentando algo semelhante. Eu estaria interessado no chipset que seu dongle possui e no driver que você está usando?

Eu tenho um baseado no chip RT3072 usando o driver rt2800usb / cfg80211. Se eu executar isso no modo mestre, ou seja, um ponto de acesso, ou como um cliente normal de um ponto de acesso / roteador, parece que ele vai dormir e demora um pouco para responder. Configurei meu laptop para executar ping no pi através do adaptador wifi em intervalos de aproximadamente 1 segundo. Confirmei que no modo mestre e no cliente, às vezes, o ping atingia o tempo limite de 5 a 10 segundos no modo cliente e de 5 a 25 segundos no modo mestre. No modo mestre, os tempos limite eram muito piores se eu executasse o AP no modo 'n' com HT e WMM habilitados no hostapd.conf. Não era tão ruim assim no 'modo g'.

Eu experimentei outro dongle wifi usando o chip RTL8188SU com o driver de teste r8712u. Infelizmente, não consegui fazer isso funcionar no modo Master, mas como cliente, era muito mais estável que o RT3072.

Com o 3072 no modo cliente, não havia atraso de ping típico - eles eram aleatórios entre 2ms e 320ms com um tempo limite ocasional. Com o 8188SU, o atraso típico do ping era de 2-3 ms, com um atraso ocasional de 166-200 ms - sem tempos limite observáveis. O que foi particularmente estranho foi que, se eu abrisse uma sessão ssh para o pi e o set top funcionasse a 0,01 s - então havia bastante carga de CPU e muito tráfego wifi, o desempenho do 3072 era bastante aprimorado. tempos de ping tipicamente 2-3ms. O carregamento teve um efeito semelhante no 3072 trabalhando no modo Master.

Não sei o que está acontecendo, mas eu ficaria mais interessado se outros usuários pudessem dedicar algum tempo a fazer um teste de ping semelhante no pi e relatar suas descobertas junto com a configuração e os drivers. Seria interessante que outras pessoas achassem que os tempos de resposta ruins e aleatórios fossem melhorados, carregando o tráfego do processador / wifi usando top como eu fiz, ou digam encontrar algo que crie algum trabalho e tráfego tcp / ip sobre o wifi.

Só para obter informações, eu tive esse problema, então procurei uma solução aqui e encontrei esta pergunta.

No entanto, mais tarde, descobri que era apenas meu Pi superaquecendo pela aparência das coisas. Uma vez tirei-o do estojo. O problema parece ter desaparecido

Para mim, funcionou editando /etc/X11/xinit/xserverrce alterando

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

de

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

Estou usando o “wheezy” do Raspbian e inicio minha sessão do X com o startx.

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

Embora eu concorde com o @goldilocks sobre o dispositivo pi não ter uma função de suspensão, o kernel ainda pode desativar a E / S específica enquanto o dispositivo estiver em execução. É por esse raciocínio que você pode tentar a seguinte edição nos arquivos KBD e reiniciar o dispositivo:

Faça a seguinte edição em / etc / kbd / config: POWERDOWN_TIME = 0

Suponho que você defina dormir como a tela desligada. Isto é o que eu achei para trabalhar:

sudo setterm -powersave off