我使用 Debian 创建了一个自己的小型服务器。昨晚我更新了它。它在生成 initrd 时出现错误,无法启动。
今天我从另一个文件系统启动并执行了dpkg --configure -a
。chroot
我还检查了文件系统。
现在一切都好了。
但是 cron 不起作用 :-( 它是相同的 /etc/crontab 文件,但它不起作用。我重新安装了 cron 并尝试了很多方法。
有没有办法查看 cron 的日志?我只读过有关 rsyslog 的内容,但我没有安装 rsyslog,因为服务器基于最小系统(Freeagent Dockstar)。
有人有想法吗?
致以最诚挚的问候 Silvio Keller
更新
没有文件/var/log/syslog
,也dpkg -l|grep syslog
没有输出,所以我认为 syslog 没有安装。它只是一个最小系统。
cron -l
给出:
cron: can't lock /var/run/crond.pid, otherpid may be 687: Resource temporarily unavailable
因此我使用以下命令停止了 cron 并再次/etc/init.d/cron stop
执行cron -l
,但没有任何输出。此时我尝试使用以下命令启动 cron /etc/init.d/cron start
:
Starting periodic command scheduler: cron failed!
但是没有其他错误信息...但我看到后台现在有一个名为的进程cron -l
正在运行。
如果我停止它/etc/init.d/cron start
就会起作用:
Starting periodic command scheduler: cron.
我使用了 crontab-file /etc/crontab
,它对我来说总是有效的。直到我更新了内核和 initrd 后,它才起作用。
该文件的内容是:
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
00 5 * * * root dummy
23 45 * * 7 root dummy
00 * * * * root dummy
*/1 * * * * root dummy
00 1 * * * root dummy
00 4 * * * root dummy
*/5 * * * * root dummy
#00 */10 * * * root dummy
01 0 * * * root dummy
00 5 * * * root dummy
00 4 * * * root dummy
#
如果我启动它,crontab -e
它会创建一个新文件/tmp/crontab.vn87tv/crontab
,但不幸的是该文件位于 tmpfs 上并且也不起作用。
谢谢并致以诚挚问候
答案1
cron 消息存储在 /var/log/syslog 中
cron -l 的输出是什么?
要使用 crontab,您必须使用 crontab -e 命令编辑文件。您还可以通过将 bash 脚本放在以下目录中之一来在 Debian 上运行 crons:
/etc/cron.hourly
/etc/cron.daily
/etc/cron.monthly
答案2
我认为最好的方法是首先修复 initrd 的错误。Cron 和 syslog 就是由此导致的。但是,如果您只想修复 Cron,则可以尝试以下操作:
cp /etc/crontab /etc/crontab.orig
- 备份以防万一;crontab /etc/crontab
- 告诉 Cron 使用 /etc/crontab(man crontab
是你的朋友)。
之后,您必须处理日志系统。您还可以尝试/var/spool/cron/crontabs
并创建用户 crontab,只是为了验证真正的问题是否出在/etc/crontab
整个 cron 系统中。另一个线索是,如果您使用旧内核重新启动,只是为了测试情况如何。