Dietpi: Проблема с cron и автоматическим резервным копированием (с v6.10-6.11)?

@eljotx
Спасибо за ваш доклад.

G_USER_INPUT=0 должен автоматически обнаруживаться при выполнении cron, поэтому назначать его не нужно. Но если вы хотите, чтобы это повлияло, вам нужно экспортировать его, что, конечно, стоит попробовать:
export G_USER_INPUT=0

При неинтерактивном выполнении сценарий завершится, если (почти) будет обнаружено недостаточно свободного места на целевом диске: https://github.com/Fourdee/DietPi/blob/master/dietpi/dietpi-backup#L456
Но вы говорите, что ручное исполнение работает нормально? В случае нехватки свободного места вы увидите подсказку, которая дает вам выбор: игнорировать или выйти.

Что касается записей журнала, ожидается несколько загадочных цветовых кодов + checking for elevation root access . Пытаться:
cat /mnt/rpi/backup.log
чтобы цветовые коды были активными и таким образом отформатировал журнал. Также предоставьте этот вывод здесь, чтобы мы могли проверить, на каком этапе возникла проблема.

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

Странный.

Попробуйте запустить задание cron и вставить результаты журнала /mnt/rpi/backup.log

NB: dietpi-backup автоматически выводит rsync в файл журнала /var/log/dietpi-backup.log , вы также можете использовать его.

Итак, я пытаюсь запустить задание cron без G_USER_INPUT = 0 (я удалил это из скрипта) и ...

Мой файл журнала резервного копирования из /mnt/rpi/backup.log
[90m[[0m[33m......[90m][0m Checking for (elevated) root access[0m

Dietpi-backup.log пуст

Я не видел никаких активных процессов после запуска cron.

Итак, я добавил к тестированию еще один скрипт, чтобы увидеть результат в файле после запуска cron:

#!/bin/sh

echo 'Cron works!' > /mnt/rpi/cronworks.log

но этот скрипт не запущен - в / mnt / rpi / нет файла cronworks.log
это странно, потому что есть выходной файл (backup.log) из моего скрипта с резервной копией (из 1-го моего сообщения), но нет из этого простого

@eljotx
Ладно, похоже, по крайней мере, ошибка cron. Обратите внимание, что cron запускает скрипты через run-parts /etc/cron.X/script и есть некоторые правила, например, скрипты должны принадлежать root (AFAIK) и, более того, скриптам не разрешено иметь окончания файлов. Это означает, что /etc/cron.daily/script.sh будет пропущено, вместо этого имя должно быть /etc/cron.daily/script .

Также в этом нет необходимости, но попробуйте использовать #!/bin/bash как shebang при использовании со скриптами DietPi. У них самих есть #!/bin/bash , но на всякий случай попробуйте использовать его также в скрипте cron.

У скрипта всегда было имя «резервная копия» (без .sh), я также меняю «#! / Bin / sh» на «#! / Bin / bash», и этот скрипт принадлежит пользователю root. Мой "тестовый" скрипт из последнего поста тоже работает.

Все перепробовал, но все равно не работает. Я меняю сценарий на печать в файл журнала после завершения одного задания, и я увидел, что сценарий запускается, но резервное копирование не началось или не завершено (диетпи-backup.log пуст), потому что не могу перейти к следующему заданию, например tar, rclone и т. Д. А еще после запуска cron увидел процесс / usr / sbin / cron -f рабочий и -bash - это нормально?

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

Я думаю, что проблема связана с использованием dietpi-backup для автоматического резервного копирования, запущенного cron. Он работал на версии 6.9, но не работал после перезаписи диетпи-бэкапа.

@eljotx
Итак, еще раз на всякий случай:

• Если выполнить вручную /DietPi/dietpi/dietpi-backup 1 успешно проходит?
• Если вы запустите G_USER_INPUTS=0 /DietPi/dietpi/dietpi-backup 1 тоже работает без ошибок, показывая что-то вроде:
  

root@VM-Jessie:~# G_USER_INPUTS=0 /DietPi/dietpi/dietpi-backup 1
[  OK  ] Root access verified.
[  OK  ] DietPi-Drive_Manager | RootFS R/W access verified.

[  OK  ] DietPi-Backup | Checking for pre-req APT packages: rsync
[ INFO ] DietPi-Backup | Flagged for installation: rsync
[  OK  ] DietPi-Backup | APT installation for: rsync, please wait...
Selecting previously unselected package rsync.
(Reading database ... 36227 files and directories currently installed.)
Preparing to unpack .../rsync_3.1.1-3+deb8u1_amd64.deb ...
Unpacking rsync (3.1.1-3+deb8u1) ...
Processing triggers for systemd (215-17+deb8u7) ...
Setting up rsync (3.1.1-3+deb8u1) ...
Processing triggers for systemd (215-17+deb8u7) ...

[  OK  ] DietPi-Backup | G_AGI: rsync

 DietPi-Backup
─────────────────────────────────────────────────────
 Mode: Backup

[  OK  ] DietPi-Backup | DietPi-Userdata validation: /mnt/dietpi_userdata
[ SUB1 ] DietPi-Services > stop
[  OK  ] DietPi-Services | occ maintenance:mode --on
[  OK  ] DietPi-Services | stop : cron
[  OK  ] DietPi-Services | stop : sonarr
[  OK  ] DietPi-Services | stop : lighttpd
[  OK  ] DietPi-Services | stop : php5-fpm
[  OK  ] DietPi-Services | stop : mysql
[ SUB1 ] DietPi-Services > stop
[  OK  ] DietPi-Services | stop : cron
[  OK  ] DietPi-Services | stop : sonarr
[  OK  ] DietPi-Services | stop : lighttpd
[  OK  ] DietPi-Services | stop : php5-fpm
[  OK  ] DietPi-Services | stop : mysql
[ INFO ] DietPi-Backup | Backing up to: /mnt/dietpi-backup
[  OK  ] DietPi-Backup | Free space check: path=/mnt/dietpi-backup/data | available=5695 MB | required=1861 MB
[  OK  ] DietPi-Backup | rsync -aH --delete --delete-excluded --exclude-from=/tmp/.dietpi-backup_filter_inc_exc -v --log-file=/var/log/dietpi-backup.log / /mnt/dietpi-backup/data/
[ INFO ] DietPi-Backup | Backup Completed:

Backup was saved to:
- /mnt/dietpi-backup
- Log file: /var/log/dietpi-backup.log
[ SUB1 ] DietPi-Services > start
[  OK  ] DietPi-Services | start : mysql
[  OK  ] DietPi-Services | start : php5-fpm
[  OK  ] DietPi-Services | start : lighttpd
[  OK  ] DietPi-Services | start : sonarr
[  OK  ] DietPi-Services | start : cron
[ SUB2 ] DietPi-Process_tool > Apply
[  OK  ] DietPi-Process_tool | Completed
[  OK  ] DietPi-Services | occ maintenance:mode --off

• Запуск точной командной строки из сценария

/DietPi/dietpi/dietpi-backup 1 > /mnt/rpi/backup.log && tar zcfv /mnt/rpi/backup.tar.gz /mnt/backup/dietpi-backup/ >> /mnt/rpi/backup.log && rclone copy /mnt/rpi/backup.tar.gz dysk: -L >> /mnt/rpi/backup.log && rm -r /mnt/rpi/backup.tar.gz >> /mnt/rpi/backup.log && reboot

также работает, показывая, что все выполнено и завершено за /mnt/rpi/backup.log ?

• run-parts --test /etc/cron.daily перечисляет ваш скрипт (если он ежедневно, в противном случае измените)
• /usr/sbin/cron -f + -bash ожидается да, так как он запускает среду bash из-за #!/bin/bash .

Если все вышеперечисленное верно, то не могли бы вы попробовать вручную запустить run-parts и посмотреть, работает ли он должным образом:

• Переместить / скопировать скрипт в отдельную папку, например ~/testdir/backup
• Тогда run-parts ~/testdir

Я тестировал, как вы показываете, и по каждому вашему вопросу: да, все работает, когда я запускаю его вручную.
Я тестировал его с помощью команды run-parts, но он все еще работает - когда я делаю это вручную.

Мой сценарий указан после использования run-parts --test /etc/cron.daily

Если я добавлю G_USER_INPUTS = 0 и запустю скрипт вручную, должен ли я увидеть экраны (хвост) с информацией о журнале и т. Д.? Потому что я всегда это вижу.

@eljotx
G_USER_INPUTS=0 просто отключает отображение меню в виде хвоста. Информация отображается только в виде сообщений терминала, а на вопросы дан ответ «нет» (отменить в случае недостаточной проверки свободного места, без просмотра журнала).

Чтобы принудительно использовать его для скрипта, вам нужно либо экспортировать его перед выполнением скрипта:

#!/bin/bash
export G_USER_INPUTS=0
/DietPi/dietpi/dietpi-backup 1

или проще просто передать это напрямую: G_USER_INPUTS=0 /DietPi/dietpi/dietpi-backup 1

Я только что понял, что вы использовали G_USER_INPUT=0 выше без S , это должно быть G_USER_INPUTS=0 с S .

Но если переменная не экспортируется, сценарии определят, можно ли вводить данные пользователем или нет. При выполнении модулей cron и, например, systemd, все сценарии DietPi должны автоматически определять и назначать G_USER_INPUTS=0 .
Вы можете убедиться, что наш метод работает, добавив в начало вашего задания cron (или тестового задания):
[[ -t 0 ]] && echo 'This environments allows user inputs' > /mnt/rpi/inputs.log || echo 'This environment does not allow user inputs' > /mnt/rpi/inputs.log
При запуске скрипта вручную он должен сообщать, что пользовательский ввод разрешен (появляются меню в виде хвостовиков), если он запускается через cron, то не должен, и никакие меню в виде хвостовиков не должны вызывать зависание скрипта.

Сначала я тестирую G_USER_INPUTS=0 и если я запускаю скрипт вручную, регистрирую:
This environments allows user inputs
иначе, если запустить cron:
This environment does not allow user inputs

Затем я пытаюсь изменить свой сценарий на это:

#!/bin/bash
export G_USER_INPUTS=0
date > /mnt/rpi/backup.log && /DietPi/dietpi/dietpi-backup 1 && (echo "Backup: DONE. " >> /mnt/rpi/backup.log && tar zcfv /mnt/rpi/backup.tar.gz /mnt/backup/dietpi-backup/ && echo "Tar backup: DONE. " >> /mnt/rpi/backup.log && rclone copy /mnt/rpi/backup.tar.gz dysk: && echo "Copy to GDrive: DONE. " >> /mnt/rpi/backup.log && rm -r /mnt/rpi/backup.tar.gz && echo "Remove tar: DONE." >> /mnt/rpi/backup.log && reboot) || echo "Backup failed!" >> /mnt/rpi/backup.log

и dietpi-backup.log по-прежнему пуст, но backup.log:

при запуске cron и автоматически запустить этот скрипт:

pon, 9 lip 2018, 18:54:01 CEST
Backup failed!

когда я запускал скрипт вручную:

pon, 9 lip 2018, 18:58:40 CEST
Backup: DONE.
Tar backup: DONE.
Copy to GDrive: DONE.
Remove tar: DONE.

Это очень раздражает ... далее в моем скрипте есть только:

#!/bin/bash
export G_USER_INPUTS=0
/DietPi/dietpi/dietpi-backup 1

и все еще не работает, если этот скрипт запускается cron.

Проблема по-прежнему с диетой-бэкапом, запущенной cron из v6.10. Я думаю, что это проблема с изменениями, которые вы внесли в v6.10 в сценарий diepi-backup.

diepi-backup.log все еще пуст

@eljotx
Спасибо за ваши усилия по тестированию.
Я пройду через наши измененные. Пока понятия не имею. По крайней мере, согласно вашим тестам, скрипт на самом деле не зависает (whiptail / G_USER_INPUTS не является проблемой), а не работает.

Провел собственное тестирование:

[......] Checking for (elevated) root access

После комментирования проверки пользователя root в dietpi-backup выполнение ее через cron приводит к:
[FAILED] RootFS is currently Read Only, unable to continue.
Но:

root@VM-Jessie:~# G_CHECK_ROOTFS_RW
[  OK  ] Root access verified.
[  OK  ] DietPi-Drive_Manager | RootFS R/W access verified.

@eljotx

tput - это проблема:
tput: No value for $TERM and no -T specified

• Интересно, как мы называли это и с v6.9 🤔.

Исправить: https://github.com/Fourdee/DietPi/commit/82ac7b32d32dca9db4fdb824c7ead80174844090

Этот патч также устраняет другую проблему: run_ntpd 1, запускаемый cron ежедневно или ежечасно, не синхронизирует время (временная метка / var / lib / systemd / clock не меняется).

@kmakisara
Йеп, ты прав, в этом есть смысл.
Чтобы избежать ручного редактирования сценария для применения исправления, все с одной и той же проблемой должны делать: wget https://raw.githubusercontent.com/Fourdee/DietPi/82ac7b32d32dca9db4fdb824c7ead80174844090/dietpi/func/dietpi-globals -O /DietPi/dietpi/func/dietpi-globals

Я думаю, что с этим связаны некоторые из наших открытых вопросов. Если run_ntpd в cron.hourly не работает, dietpi-logclear также не будет вызываться впоследствии, что приведет к заполнению / var / log: https://github.com/Fourdee/DietPi/issues/ 1920 г.

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

• Вызов анимированного уведомления о процессе v6.9: https://github.com/Fourdee/DietPi/blob/7b682286e72ef339518d110892a54e7ce405b648/dietpi/func/dietpi-globals#L301 -L315
• Изменения, внесенные в v6.10: https://github.com/Fourdee/DietPi/pull/1867/files
• tput cuu и tput cols вызывается в обоих случаях, а также tput ed в каждом другом уведомлении DietPi при очистке анимации обработки.
• Возможно, проблема была вызвана не изменениями в уведомлениях, а ошибками обработки cron (или tput) после определенного обновления.

Дальнейшее тестирование по этому поводу:

root@VM-Stretch:/tmp# cat /etc/cron.minutely/test
#!/bin/bash

echo "$TERM" &> /tmp/cron.test
tput ed &>> /tmp/cron.test
echo 'finish' &>> /tmp/cron.test
root@VM-Stretch:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified

• $TERM в cron имеет значение dumb
• tput утверждает, что для переменной нет значения, даже если оно недействительно.

root@VM-Stretch:/tmp# TERM='dumb' tput cols
237
root@VM-Stretch:/tmp# export TERM='dumb' tput cols
root@VM-Stretch:/tmp# export TERM='dumb' tput cols && echo continue
continue

• Поскольку недопустимый $ TERM не приводит к какой-либо ошибке (просто приводит к отсутствию вывода tput), ошибка cron tput, похоже, связана с отсутствием -T , [[ -t 0 ]] приводит к false. Возможно, раньше это вело себя иначе. Последнее обновление ncurses-bin APT от 15.02.2018: http://ftp.de.debian.org/debian/pool/main/n/ncurses/

• У нас уже были проблемы с неинтерактивными / недействительными терминалами, поэтому теперь выходим из сценариев diepi- *, если обнаружен пустой $ TERM или ' unknown ': https://github.com/Fourdee/DietPi/blob/ тестирование / dietpi / func / dietpi-globals # L30 -L35

• Несогласованная ставка, так как мы могли бы разрешить неинтерактивное выполнение (также без подключенного терминала), но должны позаботиться о вызове tput соответственно других команд, для которых нужен действующий терминал.

Тест на v6.9:

root<strong i="6">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
finish

• Ошибка появляется, но сценарий возобновляется.

Обновление APT не содержит cron и / или ncurses (сокращение проверенными несвязанными пакетами):

• Даже после apt-get dist-upgrade и перезагрузки cron не прекращает выполнение после ошибки tput:

root<strong i="15">@DietPi</strong>:/tmp# cat /etc/cron.minutely/test
#!/bin/bash

echo "$TERM" &> /tmp/cron.test
[[ -t 0 ]] && echo 'interactive' &>> /tmp/cron.test
tput ed &>> /tmp/cron.test
echo 'finish' &>> /tmp/cron.test
root<strong i="16">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
finish

• dietpi-update для v6.11 master: Очень странно, все еще нет проблем ...

root<strong i="22">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
finish

• Добавление выполнения диетпи-бэкапа:

root<strong i="27">@DietPi</strong>:/tmp# cat /etc/cron.minutely/test
#!/bin/bash

echo "$TERM" &> /tmp/cron.test
[[ -t 0 ]] && echo 'interactive' &>> /tmp/cron.test
tput ed &>> /tmp/cron.test
/DietPi/dietpi/dietpi-backup 1 &>> /tmp/cron.test
echo 'finish' &>> /tmp/cron.test
root<strong i="28">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
[......] Checking for (elevated) root accesstput: No value for $TERM and no -T specified
/DietPi/dietpi/func/dietpi-globals: line 266: ( 38 + 6 ) /  : syntax error: operand expected (error token is "/  ")
finish

• Скрипт не работает, но работа cron продолжается. Протестируйте с dietpi-globals v6.9:

root<strong i="34">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
         Checking for (elevated) root accesstput: No value for $TERM and no -T specified
/DietPi/dietpi/func/dietpi-globals: line 308: ((: lines=(38+6)/ : syntax error: operand expected (error token is "/ ")
tput: No value for $TERM and no -T specified
[  OK  ] Root access verified.
         DietPi-Run_ntpd | systemctl restart systemd-timesyncdtput: No value for $TERM and no -T specified
/DietPi/dietpi/func/dietpi-globals: line 308: ((: lines=(38+6)/ : syntax error: operand expected (error token is "/ ")
[..    ] tput: No value for $TERM and no -T specified
[  OK  ] DietPi-Run_ntpd | systemctl restart systemd-timesyncd
[ INFO ] DietPi-Run_ntpd | NTPD: Waiting for completion of systemd-timesyncd (1/60)
[  OK  ] DietPi-Run_ntpd | NTPD: systemd-timesyncd synced
[  OK  ] NTPD: time sync | Completed
finish

- Ладно, это связано с глобальными изменениями, но поскольку tput терпит неудачу и не работает, почему наши скрипты завершаются сейчас и не завершаются на v6.9?

Обнаружено связанное изменение: https://github.com/Fourdee/DietPi/blob/master/dietpi/func/dietpi-globals#L266
local lines=$(( (${#input_string}+6)/$(tput cols) )) приводит к выходу всего скрипта, а (предыдущий)

local lines
(( lines=(${#input_string}+6)/$(tput cols) ))

показал ошибку, но разрешил выполнение сценария (см. выше).

Исправить https://github.com/Fourdee/DietPi/commit/82ac7b32d32dca9db4fdb824c7ead80174844090 работает и также является самым чистым решением, поскольку tput будет полностью пропущено в неинтерактивных оболочках. Но чтобы избежать сбоев, мы должны вернуться к предыдущему методу, чтобы сначала объявить переменную, а затем присвоить значение в арифметической среде: Выполнение фиксации https://github.com/Fourdee/DietPi/commit/0f18aa4dc0af8ab910a0173dce8849d5b53c30b0

@eljotx @kmakisara
Чтобы очистить заявку, я открыл новую проблему, попробуйте применить исправление, упомянутое там, и сообщите, если оно решит все проблемы: https://github.com/Fourdee/DietPi/issues/1923

Закрою этот выпуск в пользу нового.

Я мог успешно использовать ssh в свою v6.13, но он зависал сразу после этого.

Команда «tput cols» выводила tput: unknown terminal «rxvt-256color» , что приводило к пустому значению в строке 328 диетпи-логина, что заставляло его зависать навсегда после успешного чтения базы данных при начальной загрузке.

Экспорт TERM = xterm, уродливый хакер, похоже, исправил сценарий входа в систему, и теперь можно начинать установку.

Если это неправильный раздел, проявите терпение, потому что я действительно не знаю, как использовать проблемы с github; Я нашел этот поток после нескольких часов бесполезного поиска в Google для ошибки, если вы переместите его, возможно, останется остаток об ошибках rxvt-256color, на случай, если у кого-то есть моя такая же проблема.

С наилучшими пожеланиями!

@wuhei

Здравствуй,

Спасибо за отчет и решение 👍

Какой у вас SSH-клиент?

@Fourdee
Я открывал для этого отдельный выпуск. Выявлена ​​проблема: https://github.com/Fourdee/DietPi/issues/2034

@wuhei
После входа в SSH попробуйте: export TERM='xterm-256color' €: А, это в основном то, что вы уже узнали 😄.
Если это сработает, вы можете добавить сценарий в /etc/profile.d/ , содержащий что-то вроде:
[[ $SSH_TTY ]] && [[ $TERM =~ 256 ]] && export TERM='xterm-256color'

• Проще говоря: если это SSH-соединение, и SSH-клиент передал 256-битный цветной терминал, настройте его на xterm-256color , который поддерживается DietPi.

Альтернативой может быть установка пакета, который содержит больше определений терминала: G_AGI ncurses-term

@Fourdee OpenSSH_7.7p1, OpenSSL 1.1.0h в Arch Linux

@MichaIng, спасибо, рад, что смог помочь случайно!

Пожалуйста, имейте в виду, что я плохой системный администратор, и, прочитав эту статью Тома Райдера, я обнаружил, что у меня довольно неправильно настроенная конфигурация "объявления" терминала.

В конце концов, проблема была решена для меня

• экспорт правильного $ TERM в /root/.bashrc
• копирование правильной записи terminfo из моей установки Arch в папку pi /root/.terminfo

Я не смог скопировать файл terminfo на свой пи, потому что scp не установлен (возможно, подумайте об установке его вместе с сервером dropbear?), Поэтому я загрузил его на свой сервер и просто получил его с пи.

Рад, что смог помочь, приветствую и еще раз извиняюсь за беспорядок - вперед!

@wuhei
Jep, установка $ TERM в /root/.bashrc конечно, тоже работает, добавление ее в /etc/profile[.d/] решает проблему в масштабах всей системы для всех пользователей, что является решением, которое мы выбрали бы с DietPi.

Статья, на которую вы ссылаетесь, довольно хороша, очень хорошо объясняет все и возможности 👍. Таким образом, вы в основном устанавливали требуемый тип терминала вручную. В статье также упоминается пакет ncurses-term как вариант установки широкого диапазона определений терминалов. Но для того, чтобы DietPi оставался тонким, я не очень хочу предварительно устанавливать этот пакет для таких редких случаев. Вместо этого лучше использовать решение bashrc / profile; Также можно просто проверить поддержку терминала перед применением исправления при входе в систему по SSH.

Для тестирования с клиентом PuTTY: PuTTY> Connection > Data > Terminal-type string

Об установке SCP: Есть несколько других протоколов передачи файлов, FTP, SFTP или сетевые диски NFS, SMB для передачи файлов. Я бы не стал выполнять предварительную установку, но оставил выбор пользователю, как передавать файлы с клиента на сервер. USB-накопитель, внешний накопитель, конечно, также возможен или просто скопируйте и вставьте в терминал SSH в случае. Но в любом случае в качестве общего решения я бы выбрал один из двух способов, упомянутых выше.