在我的工作中,我们有一个运行 Debian Wheezy 的中央备份服务器,以及每个站点的现场服务器,也运行 Debian Wheezy。
几周前,中央办公室技术人员给我发电子邮件说备份在前一天晚上没有正确完成。此后我们一直在进行故障排除,但似乎仍然无法解决问题。唯一反驳的是一封cron
电子邮件中的以下内容:
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(549) [generator=3.0.9]
rsync error: received SIGUSR1 (code 19) at main.c(1316) [receiver=3.0.9]
谷歌搜索这个短语几乎一无所获。我找到了 2002 年关于删除开关的帖子-v
,但脚本中没有使用它。每晚运行的脚本如下:
#!/bin/sh
set -e
x="delete --exclude-from=r_filter --delete-excluded"
rsync -aq --$x site1.company.com:/etc /BACKUPS/site1
rsync -aq --$x site1.company.com:/home /BACKUPS/site1
它设置为周一至周五凌晨 3:00 从中央备份服务器运行。如果他们尝试在白天手动运行它,它会运行良好(因为大多数文件之前都已备份?)。它使用-a
开关,所以我认为它可以存档打开的文件?我能想到的就这么多了。
为了解决这个问题,我们的下一步是什么?
答案1
如果在某个时间在 crontab 中运行作业时发生了某些情况,而如果您在一分钟内运行该作业进行测试则不会发生这种情况,则有两种可能的可能性:
- crontab 上还有另一个进程会以某种方式干扰您的进程。
- 当时正在进行一个人为的过程,比如清洁人员拔掉电脑的插头来插上吸尘器的插头。
您的 rsync 进程在晚上的某个时间接收信号。我首先要查找的是 crontab 中的另一个进程是否发送了它不应该发送的信号。
(如果从命令行运行正常但从 cron 运行时失败,这是完全不同的一锅鱼.)
答案2
您可以尝试使命令不受信号影响,以防再次发生这种情况,同时如果信号通过同一进程组中的某个父进程定向到您的 shell,则在后台捕获信号。例如:
#!/bin/bash
( trap 'echo got signal; date; ps ax; kill $pid; exit' sigint sigterm sighup
sleep 999999 &
pid=$!
wait
) &
trap '' sigint sigterm sighup
rsync ...
rsync ...
kill -hup $!
将trap ''
忽略以下命令中列出的 3 个信号。中的背景部分()
将捕获信号,并执行例如ps
或类似操作,以查找此时正在运行的内容。
我会寻找一些愚蠢的东西,比如logrotate
发出这种信号的过度热情的命令。