Dietpi: cron和自动备份的问题（来自v6.10-6.11）？

@eljotx
感谢您的报告。

实际上应在cron执行时自动检测G_USER_INPUT=0 ，因此不必分配。 但是，如果您希望它产生影响，则需要导出它，这当然值得尝试：
export G_USER_INPUT=0

在非交互式执行中，如果在目标驱动器上检测到（接近）不足的可用空间，脚本将退出： https :
但是您说手动执行可以吗？ 在可用空间不足的情况下，您会看到鞭打提示，然后您可以选择忽略或退出。

关于日志条目，预计将使用一些神秘的颜色代码+ checking for elevation root access 。 尝试：
cat /mnt/rpi/backup.log
使颜色代码处于活动状态并因此格式化日志。 另外，请在此处提供此输出，以便我们可以检查问题发生在哪个阶段。

当我手动运行脚本时，脚本运行良好。

奇怪。

尝试运行cron作业并粘贴日志结果/mnt/rpi/backup.log

注意： dietpi-backup自动将rsync输出到日志文件/var/log/dietpi-backup.log ，您也可以使用它。

因此，我尝试在没有G_USER_INPUT = 0的情况下运行cron作业（我从脚本中删除了此作业），并且...

我的备份日志文件来自/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）（从我的第一篇文章开始），但是从这个简单的文件中没有

@eljotx
好的，似乎cron至少也有错误。 请注意，cron通过run-parts /etc/cron.X/script启动脚本，并且有一些规则，例如，脚本必须归root（AFAIK）所有，并且更确定脚本不允许以文件结尾。 这意味着将跳过/etc/cron.daily/script.sh ，而名称应改为/etc/cron.daily/script 。

另外，它也不是必需的，但是在与DietPi脚本一起使用时，请尝试使用#!/bin/bash作为shebang。 那些本身具有#!/bin/bash ，但是为了安全起见，请尝试在cron脚本中也使用它。

脚本始终具有“备份”名称（不带.sh），我也将脚本中的“＃！/ bin / sh”更改为“＃！/ bin / bash”，并且该脚本由root拥有。 我上一篇文章的“测试”脚本现在也可以工作。

我尝试了所有操作，但仍然无法正常工作。 完成一项工作后，我将脚本更改为打印到日志文件，但我看到脚本已启动，但备份未启动或完成（dietpi-backup.log为空），因为无法进行下一个工作，例如tar，rclone等而且在运行cron之后，我还看到了/ usr / sbin / cron -f工作和-bash进程-正常吗？

如果我手动运行脚本，脚本仍然可以工作-但是备份完成后，必须单击“确定”和“取消”（打扰屏幕），然后–下一个作业开始。

我认为问题出在使用Dietpi-backup自动备份cron启动的备份。 它适用于6.9版本，但在重写Dietpi-backup后无作用。

@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是，因为#!/bin/bash会启动bash环境。

如果以上所有内容都是正确的，那么您是否可以尝试手动启动运行部件并查看其是否按预期执行：

• 将脚本移动/复制到单独的文件夹中，例如~/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开始的Dietpi-backup。 我认为这是您在Dietpi-backup脚本中在v6.10中所做的更改的问题。

Dietpi-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 :

此修补程序还解决了另一个问题：cron每天或每小时运行的“ run_ntpd 1”不同步时间（/ var / lib / systemd / clock的时间戳不变）。

@kmakisara
没错，没错，这很有意义。
只是为了避免手动编辑脚本以应用修订，所有具有相同问题的都应该这样做： wget https://raw.githubusercontent.com/Fourdee/DietPi/82ac7b32d32dca9db4fdb824c7ead80174844090/dietpi/func/dietpi-globals -O /DietPi/dietpi/func/dietpi-globals

我认为我们一些未解决的问题与此有关。 如果cron.hourly内的run_ntpd失败，则以后也不会调用dietpi-logclear ，导致/ var / log填满： https :

我只是想知道，为什么这个问题首先出现在v6.10 +上，因为我们之前在cron作业中已经使用了tput 。
也许有人可以找到导致问题的更改，所以我们知道将来如何更好地进行处理：

• 调用动画过程通知v6.9： https :
• 使用v6.10进行的更改： https :
• 在两种情况下都将调用tput cuu和tput cols ，以及在清除处理动画时在每隔Diet Diet通知中调用tput ed 。
• 导致问题的原因可能不是通知的更改，而是某些更新后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

• 在cron上将$TERM设置为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更新于2018-02-15： http :

• 我们已经遇到了非交互/无效终端的问题，因此，如果找到空的$ TERM或' unknown '，现在退出Dietpi- *脚本： https :

• 出价不一致，因为我们可能希望允许非交互式执行（也没有连接任何终端），但是需要注意分别调用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管理员：Veeery很奇怪，仍然没有问题...

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

• 添加Dietpi备份执行：

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 :
local lines=$(( (${#input_string}+6)/$(tput cols) ))导致整个脚本退出，而（上一个）

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

显示错误，但允许脚本继续执行（请参见上文）。

修正https://github.com/Fourdee/DietPi/commit/82ac7b32d32dca9db4fdb824c7ead80174844090的工作原理，并且也是最干净的解决方案，因为tput将在非交互式shell中被完全跳过。 但是为了安全起见，我们应该恢复到先前的方法，首先声明变量，然后在算术环境中分配值：提交完成https://github.com/Fourdee/DietPi/commit/0f18aa4dc0af8ab910a0173dce8849d5b53c30b0

@eljotx @kmakisara
要清理出价，我打开了一个新问题，请尝试应用此处提到的修复程序并报告，如果它可以解决所有问题，则请返回： https :

我将以新的问题结束这个问题。

我可以成功将ssh插入我的v6.13，但之后会挂起。

“ tput cols”命令正在输出tput：未知终端“ rxvt-256color” ，导致Dietpi登录第328行的值为空，使其在首次启动后成功读取数据库后便永远挂起。

导出TERM = xterm是一个丑陋的骇客，似乎已经修复了登录脚本，现在可以开始安装了。

如果这是错误的部分，请耐心等待，因为我真的不知道如何使用github问题； 在经过数小时无用的搜索错误后，我发现此线程，如果您将其移动，则可能会留下关于rxvt-256color错误的余地，以防万一有人遇到我同样的问题。

最好的祝福！

@wuhei

你好

感谢您的报告和解决方案👍

您正在运行哪个SSH客户端？

@福迪
我为此打开了一个单独的问题。 确定了问题： https :

@wuhei
登录SSH后，请尝试： export TERM='xterm-256color' €：基本上，这就是您已经发现的😄。
如果可行，您可以将脚本添加到/etc/profile.d/ ，其中包含以下内容：
[[ $SSH_TTY ]] && [[ $TERM =~ 256 ]] && export TERM='xterm-256color'

• 换句话说：如果这是SSH连接，并且SSH客户端通过了256位彩色终端，则将其调整为DietPi支持的xterm-256color 。

一种替代方法是安装一个包含更多终端定义的软件包： G_AGI ncurses-term

@ Arch Linux上的

@MichaIng谢谢，很高兴我能提供帮助！

请记住，我是一个糟糕的系统管理员，通过阅读Tom Ryder的这篇文章，我发现我有一个配置错误的终端“声明”配置。

最后，对我来说解决的问题是

• 在/root/.bashrc中导出正确的$ TERM
• 从pi的/root/.terminfo文件夹中的arch安装中复制正确的terminfo条目

我无法将terminfo文件scp到我的pi，因为未安装scp（也许考虑将其与dropbear服务器一起安装？），所以我将其上传到我拥有的服务器上，只是从pi中获取了它。

很高兴我能为您提供帮助，欢呼，并为造成的混乱再次表示抱歉-继续前进！

@wuhei
Jep，当然也可以在/root/.bashrc内设置$ TERM，将其添加到/etc/profile[.d/]可以解决所有用户的系统问题，这是我们使用DietPi的解决方案。

您链接的文章非常好，很好地解释了所有内容和可能性。 因此，您基本上是手动安装所需的终端类型。 本文还提到ncurses-term软件包作为安装各种终端定义的选项。 但是，为了使DietPi苗条，我不太想在这种罕见情况下预安装此软件包。 更好的是，使用bashrc / profile解决方案。 在对SSH登录应用修复程序之前，还可以简单地检查终端支持。

对于使用PuTTY客户端进行测试：PuTTY> Connection > Data > Terminal-type string

关于安装SCP：还有其他几种文件传输协议，即FTP，SFTP或网络驱动器NFS，SMB，用于传输文件。 我不会进行预安装，但要让用户选择如何从客户端到服务器获取文件。 当然也可以使用USB记忆棒，外部驱动器，或者将其复制粘贴到SSH终端中，以防万一。 但是无论如何，作为通用解决方案，我将采用上述两种方式之一。