Спящий режим Raspberry Pi, как избежать


32

Я использую "wheezy" последний выпуск. Устройство предоставляет некоторые функции веб-службы и предполагает свою активность в режиме 24/7. Однако, если сервер не был запрошен в течение определенного времени (трудно сказать точное время), устройство, кажется, собирается спать (мы надеемся, что не произойдет сбой). Устройство подключено к сети с помощью Wi-Fi-ключа. Я нашел некоторые ответы здесь, что причиной зависания устройства может быть то, что карта Wi-Fi переходит в экономичный режим, поэтому я следовал инструкциям и могу подтвердить, что ключ не засыпает, но он начинает мигать, как будто его не обслуживают компьютер. это означает, что устройство все еще спит, хотя Wi-Fi не спит. Решение, как купить другой Raspberry Pi и заставить его все время пинговать в спящем режиме, не работает, так как только сервер, получающий запросы, предотвращает переход устройства в спящий режим. Попытка опросить что-то с устройства не мешает переходить в спящий режим. Я не могу на самом деле подтвердить, что устройство идет спать. У меня не подключен монитор или клавиатура, и попытка установить что-либо приводит к перезагрузке устройства. Так что я в настоящее время не знаю, что может вызвать поведение. И да, я применил все средства, предотвращающие сбои ОС, как без турбо, и увеличил минимальный размер памяти виртуальной машины


Есть ли что-нибудь в файлах / var / log, показывающее, что что-то происходит, идет спать, выключается устройство?
Колин

2
Для потомков, пожалуйста, обратите внимание, что аппаратное обеспечение pi не имеет потенциального режима сна, приостановки и т . Д. Это либо работает, либо нет. Если он подключен, индикатор питания будет гореть в любом случае.
Златовласка

Это не только ваш Wi-Fi ключ. Я подключил мой через Ethernet-порт для обслуживания веб-запросов, и через некоторое время он «засыпает» (или что-то близкое к этому состоянию) и больше не будет обслуживать запросы. Если я нажму несколько клавиш, чтобы разбудить его, он снова начнет работать. Но это боль, потому что единственное время, когда мне нужно, чтобы обслуживать запросы, - это когда меня нет, чтобы разбудить его.

У меня была эта проблема с Пи, видимо, идущей спать. Я могу случаться каждые несколько минут и может длиться около 20 секунд. Это очевидно, когда я пытаюсь получить доступ к файлу через общий ресурс Samba или когда я SSHing в Pi - все просто останавливается. Я подумал, что это может быть Пи, который был под нагрузкой, поэтому я побежал «сверху». Там не было никаких доказательств тяжелой нагрузки. Тем не менее, я обнаружил, что при запуске «top» Pi работал отлично. Доступ к файлам был быстрым, и соединения SSH не испытывали перебоев. Итак, я не могу сказать, что вызывает эту проблему, но это не высокие требования к процессору, наоборот, Pi
Brian

Ответы:


9

Я использовал простые шаги, и это отлично сработало для меня:

  1. Откройте корневой терминал в Raspberry Pi. Теперь вам нужно отредактировать ваш скрипт, который запускает X. В сборке по умолчанию с lightdm.

  2. Откройте файл "lightdm.conf", расположенный в,

    /etc/lightdm/lightdm.conf

  3. Добавьте строку ниже в SeatDefault(или Seat:*в более новых версиях LightDM).

    [SeatDefaults]

    xserver-command = X -s 0 -dpms

  4. Перезагрузите Raspberry Pi.

Теперь проблема должна быть решена.

Ссылка на источник: http://chamaras.blogspot.com/2013/03/how-to-deactivate-monitor-sleep-in.html


1
Добро пожаловать в Stack Exchange. Здесь мы ожидаем, что ответы будут самостоятельными, а не просто ссылками на внешние источники. Если вы сможете добавить соответствующую информацию в свой ответ, тогда это будет намного лучше.
Jivings

Пожалуйста, добавьте информацию, которая находится на этом сайте: ссылки не являются приемлемыми ответами.
xxmbabanexx

1
спасибо за лучший ответ, творит чудеса даже в 2017 году
Sverre

8

Что-то не так. У пи нет "спящего режима".

У меня был мой пи всего несколько недель, и я не оставлял его все время, но я намерен в конечном итоге и оставил его на несколько долгих отрезков. Я использую Rasbian, и у меня есть личная неприязнь к NetworkManager, так что это отключено. Чтобы поддерживать Wi-Fi, я запускаю скрипт, который пингует маршрутизатор каждые пять секунд. Если пинг не удается, он убивает текущий dhcpcd и пытается установить Wi-Fi каждые 5 секунд, пока это не удастся. Он регистрирует попытки, и фактически уже более 24 часов без необходимости повторного подключения, и когда я захожу в ssh, проблем не возникает.

Вы уже сказали: «Попытка опросить что-то с устройства не мешает переходить в спящий режим», поэтому я хочу сказать, что моя проблема, очевидно, не имеет этой проблемы, поэтому что-то не так.

Вы говорите, что он «спит», но похоже, что вам действительно нужно перезагрузиться. Почему ты веришь, что это спит? AFAICT, пи не может заснуть, у него нет такой возможности. Погуглив, кажется, есть некоторая путаница по этому поводу со стороны людей, которые имеют такие же проблемы, как ваша.

Помните, что при подключении к источнику питания горит красный светодиод, независимо от того, работает ли пи или нет. Но пи либо загружен и работает, либо остановлен, у него нет режима сна, ожидания, гибернации и т . Д.

Таким образом, ваш пи либо потерпел крах, либо остановился, либо находится в каком-то ошибочном замороженном состоянии. Убедитесь, что он более чем теплый, что указывает на то, что процессор находится в постоянном цикле занятости (одна из причин, по которой он может быть включен, но не отвечает).

Я предполагаю, что одна из причин, по которой вы считаете, что он спит, заключается в том, что «попытка прикрепить что-либо приводит к перезагрузке устройства». Это может произойти, когда устройство полностью остановлено (попробуйте); это потому, что некоторые устройства будут вызывать кратковременное падение напряжения (но см. ПРИМЕЧАНИЕ) при первом подключении, что равносильно отключению pi, а затем подключению его снова - что, как вы знаете, подключение его вызывает его загрузку. Мой нано-размер WiFi ключ сделает это.

ПРИМЕЧАНИЕ: На самом деле наш пи был, вероятно, сделан с прошлого августа, когда полифусы были заменены на «шорты» - я очень мало знаю об электронных компонентах или электричестве, но, очевидно, проблема WRT с перезагрузкой с USB-устройств остается той же .


6

Я знаю, что это старый вопрос, но это был первый результат, который появился в моем поиске, когда у меня возникла та же самая проблема на моем недавно установленном Pi Zero.

Я нашел ключ к моему ответу на этот другой вопрос , среди других источников.

Таким образом, в принципе, хотя сам Pi, по-видимому, не имеет спящего режима, отдельные устройства в Linux (включая сетевые адаптеры) могут. Когда я пытался запустить команду, iw wlan0 get power_saveкак упомянуто выше, я сначала получал сообщение об ошибке. Это было исправлено путем обновления ОС:

sudo apt-get update && apt-get upgrade

Затем я перезагрузился: sudo reboot now

После этого iwкоманда проверила, что режим power_save действительно включен. Итак, я выключил это:

sudo iw wlan0 set power_save off

С тех пор все хорошо. Мой экран переходит в спящий режим, но сетевое соединение остается активным, и я могу подключиться к своему Pi даже после некоторого простоя.


1
Хедз-ап, мне нужно было использовать sudo iw dev wlan0 set power_save off(там нужно было dev)
n0nag0n

Этот не работает для меня. Несмотря на то, что мое устройство WLAN названо, wlan0я получаюcommand failed: No such device (-19)
gromit190

@ n0nag0n я могу подтвердить , что iwожидает либо devили в phyкачестве второго аргумента, в зависимости от того, как вы обратитесь к беспроводному устройству. Я также добавил бы, что команда, вероятно, должна запускаться после каждой перезагрузки.
Дмитрий Григорьев

5

Похоже, ваш Wi-Fi ключ начинает пульсировать, как ноутбук в режиме ожидания, но вы еще не подтвердили, что сам Pi выключается. Я испытываю ту же проблему.

Я пробовал это, но не применял это достаточно долго, чтобы знать, решило ли это мою конкретную проблему: https://raspberrypi.stackexchange.com/a/4518/4271


1

Я бы проверил наличие проблем с питанием. Подключение устройств, вызывающих перезагрузку RPI, никак не связано с каким-либо спящим режимом.

В качестве быстрого теста я бы сделал это - напишу небольшой скрипт (python / will, все, что удобнее) и заставлю его отправлять простое электронное письмо «Я хороший» и помещать его в ваш crontab для выполнения каждые 30 минут или около того, и посмотрим как пойдет.


0

Интересно, испытываю ли я что-то подобное? Я был бы заинтересован в чипсете вашего ключа и драйвере, который вы используете?

У меня есть один на основе чипа RT3072 с использованием драйвера rt2800usb / cfg80211. Если я запускаю это либо в режиме Master, то есть в точке доступа, либо в качестве обычного клиента для точки доступа / маршрутизатора, это выглядит так, как будто он переходит в спящий режим и для ответа требуется некоторое время. Я настроил свой ноутбук на пинг пи через адаптер Wi-Fi с интервалом примерно в 1 секунду. Я подтвердил, что как в режиме мастера, так и в режиме клиента время от времени пинг истекает ~ 5-10 секунд в режиме клиента и 5-25 секунд в режиме мастера. В режиме master время ожидания значительно ухудшилось, если я запустил точку доступа в режиме 'n' с включенным HT и WMM в hostapd.conf. Это было далеко не так плохо в «режиме g».

Я экспериментировал с другим ключом Wi-Fi, используя чип RTL8188SU с промежуточным драйвером r8712u. К сожалению, я не смог запустить его в режиме Master, но в качестве клиента он был намного стабильнее, чем RT3072.

С 3072 в режиме клиента не было типичной задержки пинга - они были случайными от 2 мс до 320 мс со случайным таймаутом. При 8188SU типичная задержка пинга составляла 2-3 мс, а случайная задержка 166-200 мс - без видимых таймаутов. Что было особенно странно, так это то, что если я открыл сеанс ssh для pi и установил максимальную скорость 0,01 сек., Так что нагрузка процессора была довольно высокой, а трафик Wi-Fi «большой», производительность 3072 значительно улучшилась. время пинга обычно 2-3 мс. Загрузка оказала аналогичное влияние на 3072, работающий в режиме Master.

Я не знаю, что происходит, но мне было бы очень интересно, если бы другие пользователи могли потратить время на проведение аналогичного теста ping на своем пи и сообщить о своих выводах вместе со своей конфигурацией и драйверами. Было бы интересно, если бы другие находили плохое и случайное время отклика, улучшая загрузку трафика процессора / Wi-Fi, используя top, как я, или, скажем, найти что-нибудь, что создает некоторую работу и трафик tcp / ip по Wi-Fi.


На самом деле это не ответ, однако он содержит достаточно подробное содержание, которое, вероятно, не поместится в разделе комментариев исходного вопроса
Колин

Спасибо за подсказку Колин - я новичок в этом форуме и еще не все понял!
Ivo

Я попытался реализовать ответ Стефана - отключить управление питанием (для драйверов cfg80211 / mac80211 вы можете использовать iw wlan0 set power_save off), и это сильно изменило режим клиента - случайные задержки пинга теперь довольно устойчивы на 2-3 мс и таймаутов пока нет. Это не помогло с режимом AP (power_save off не подходит для моего устройства), но я не думаю, что это является источником проблемы в режиме AP, поскольку время пинга в общем случае стабильно. Что-то еще вызывает таймауты. Не ясно, была ли конфигурация в исходном вопросе для режима клиента или точки доступа.
Ivo

0

Просто для информации, у меня была эта проблема, поэтому искал решение здесь и нашел этот вопрос.

Однако позже я узнал, что это был просто мой Пи перегревается от внешнего вида. Однажды я вынул его из своего дела. Проблема, кажется, исчезла



-1

Хотя я согласен с @goldilocks о том, что у устройства pi нет функции сна, ядро ​​может по-прежнему отключать определенные устройства ввода-вывода во время работы устройства. Именно по этой причине вы можете попробовать следующее редактирование в файлах KBD и перезагрузить устройство:

Сделайте следующее редактирование в / etc / kbd / config: POWERDOWN_TIME = 0


-1

Я предполагаю, что вы определяете сон как выключение экрана. Вот что я нашел для работы:

sudo setterm -powersave off

Вопрос конкретно гласит: «У меня нет монитора или клавиатуры».
Дмитрий Григорьев

Если он подключен к сети, постер может просто войти. Почему голосование за?
Аллан Цао
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.