Перезагрузка WirenBoard по расписанию


#1

В целях исключения зависаний есть желание принудительно раз в сутки (например в 02.00) перегружать полностью контроллер.
Вопрос с учётом того, что вот такая запись в питоне не работает:
subprocess.call(‘reboot -i’)
работает только так: subprocess.call(‘reboot’)
Какие альтернативные способы есть? использовать cron?


#2

а чего он у вас зависает то? Если у вас зависает контроллер, надо или причину искать или менять его.


#3

Вот зависать он вряд-ли у Вас будет.
Из огромного количества установленного нами контроллеров ни разу не сталкивались с этим.
А вот чуть что ватчдог сам перезагружает, даже если не зависло, а просто ‘сильно тупит’


#4

Ну ловил что вот в этих фрагментах кода:
"
conn = SerialPort(PORT_NAME)
try:
conn.connect()
except:
logger.critical(‘Cannot connect to serial port %s’ % PORT_NAME)
raise SystemExit(1)"
а также
“while status:
# Если куча ошибок, то отправим в ребут
if errors_count > 20:
logger.info(‘reboot…’)
subprocess.call(‘reboot -i’)”

как раз контроллер впадает в нирвану… код не мой, я вообще ни питон, ни тем более линукс не знаю от слова совсем. Какие ещё баги и глюки оставили авторы - понятия не имею, однако понимаю, что неверно ни raise SystemExit(1) ни subprocess.call(‘reboot -i’), контроллер просто виснет. Есть ещё объекты, на которых контроллеры точно виснут, видимо из-за программных ошибок. Но, повторюсь, нюансов много, я вообще линукс не знаю. Кроме того и модем тоже может зависнуть. Поэтому мне проще раз в сутки контрольно его перегрузить. Ну и собственно вопрос был безотносительно надёжности либо причин. Просто - можно или нельзя. Если можно - то как?


#5

WB5 и старше лучше перезагружать командой halt. Это вызовет срабатывание аппаратного watchdog после завершении работы линукса, соответственно вся периферия на плате будет гарантировано перезагружена по питанию.


#6

ну во-первых это отрывки кода, а во-вторых в каком это измерении оборудование перезагружается по “если куча ошибок”? Чем перезагрузка поможет?
Кстати, а на чем у вас код написан?


#7

Давайте не будем опускаться в словоблудие и стебание по поводу и без… Я уже говорил, что код не мой, все вопросы и “язвы” пожалуйста к автору. “Он художник, он так мыслит”. Во вторых да, это отрывки кода. Просто именно на них всё и спотыкается. Код на питоне.
Предлагаю всё-таки отвлечься от конкретики, мне и так нелегко ковыряться в новой области для меня, а Вы про измерения… А вот на изначальный вопрос так и не ответили.


#8

Спасибо. поменяю


#9

я ни разу не язвил.
а перезагрузку можно поставить в cron, гуглите “настройка cron”

в вашем случае это выглядит примерно так:

00 2 * * * root /sbin/halt --reboot

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


#10

Спасибо. а можете пояснить почему вот так не работает: subprocess.call(‘reboot -i’)" а вот так работает:“subprocess.call(‘reboot’)”? Не допускаются пробелы? ибо из командной строки-то работает…


#11

я не в курсе что такое ключ -i, вы ничего не перепутали?
ну и не знаю какие отношения у питона с шелом, а так же под каким пользователем работает ваш скрипт.


#12

вот лог PuTTY
если через строку вручную - всё работает:
login as: root
root@192.168.1.140’s password:
Linux wirenboard-A4GSTH33 4.1.15-imxv5-x0.1 #244 Thu Mar 30 17:01:24 MSK 2017 armv5tejl

Last login: Thu Sep 20 00:46:46 2018 from 192.168.1.77
root@wirenboard-A4GSTH33:~# reboot -i

The system is going down for reboot NOW!4GSTH33 (pts/2) (Thu Sep 20 16:55:08
root@wirenboard-A4GSTH33:~#


#13

где тут про ключ -i ?

reboot [OPTIONS…] [ARG]
Reboot the system.
–help Show this help
–halt Halt the machine
-p --poweroff Switch off the machine
–reboot Reboot the machine
-f --force Force immediate halt/power-off/reboot
-w --wtmp-only Don’t halt/power-off/reboot, just write wtmp record
-d --no-wtmp Don’t write wtmp record
–no-wall Don’t send wall message before halt/power-off/reboot

а скрипт питоновский у вас от какого пользователя работает?


#14

НУ так у автора было, я думал он умный, ему видней.
Эээ… я щас тупой вопрос встречный задам - а как это выяснить (про пользователя)? сам main.py в руте лежит. Я как-то думал что по априори должно всё от рута работать…

о! нашёл! DAEMON_USER=root


#15

что там написано это хорошо, но лучше посмотреть реальный процесс:

ps -Af


#16

“root 2774 1 10 16:56 ? 00:23:55 /usr/bin/python3 /root/gb/main.py”
у меня есть подозрение что “-i” - это ошибка, а командная строка видимо просто ее игнорирует, а call - не игнорирует, так как там скобки и просто вылетает… Спасибо за помощь


#17

да, вполне может быть