Cron 运行一个不存在的 . sh脚本

Cron 运行一个不存在的 . sh脚本

我遇到过一个奇怪的现象。

我一直在搞乱cron,所以它运行一个名为 的脚本startup.sh,它确实做到了。

我使用了该命令sudo crontab -e,然后输入以下内容:

@reboot sleep 20 && /home/hellfire/startup.sh

首先我编写了发送电子邮件的脚本,但后来我重写了它以发送消息。然而,当重新启动服务器时,什么也没有发生。

然后我检查了 cron 的状态,很惊讶它已经运行了旧脚本,现在已经不存在了。有某种 cron 缓存吗?

我在这里检查状态:

hellfire@Plex:~$ sudo systemctl status cron

    ● cron.service - Regular background program processing daemon
       Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
       Active: active (running) since Mon 2020-01-20 20:57:56 CET; 1min 45s ago
       Docs: man:cron(8)
       Main PID: 537 (cron)
      Tasks: 1 (limit: 3548)
       CGroup: /system.slice/cron.service
               └─537 /usr/sbin/cron -f

    Jan 20 20:57:57 Plex cron[537]: (CRON) INFO (pidfile fd = 3)
    Jan 20 20:57:57 Plex cron[537]: (CRON) INFO (Running @reboot jobs)
    Jan 20 20:57:57 Plex CRON[565]: pam_unix(cron:session): session opened for user root by (uJan 20 20:57:57 Plex CRON[613]: (root) CMD (sleep 20 && /home/hellfire/startup.sh)
    Jan 20 20:58:21 Plex sSMTP[866]: Creating SSL connection to host
    Jan 20 20:58:21 Plex sSMTP[866]: SSL connection using ECDHE_RSA_AES_256_GCM_SHA384
    Jan 20 20:58:21 Plex cron[537]: sendmail: 550 5.7.1 Username [email protected] and sender roJan 20 20:58:21 Plex sSMTP[866]: 550 5.7.1 Username [email protected] and sender [email protected] 20 20:58:21 Plex CRON[565]: (root) MAIL (mailed 75 bytes of output but got status 0x00                                )
    Jan 20 20:58:21 Plex CRON[565]: pam_unix(cron:session): session closed for user root

它尝试运行不再存在的邮件脚本,但失败了(以前有效,但这不是问题)

然后我检查了脚本文件:

hellfire@Plex:~$ cat /home/hellfire/startup.sh

#!/bin/bash

smsT --command='m "Adam Larsson" Hellfire are ONLINE'

这是新脚本,那么 cron 从哪里运行另一个(现在重写的脚本)呢?

我当然重新启动了Linux,我什至尝试清除缓存,但它不起作用..

..所以现在我很困惑...(比平常更困惑)。有谁知道这方面的事情吗?

在 Ubuntu 18.04.3lts mini 上运行

答案1

这是经典”追逐自己的尾巴“ 问题。

如果 cron 作业发生错误,cron 将从当前运行的用户帐户发送一封电子邮件到系统上当前邮件配置中指定的电子邮件。

由于第一个脚本是通过电子邮件通知的,我假设(一个错误的假设)cron 正在运行该脚本的一些奇怪的“幽灵副本”,但它只是在完成它的工作。

是@kusalananda 让我走上了正轨。

我觉得好奇的是,我写这个作为答案的原因是 cron 从未说过新脚本有任何问题,除了它无法发送电子邮件之外。 22 的一个小时刻,焦点被放在了错误的问题上。

这当然不是最佳答案,但这一次是SBK错误 (S愚蠢的后面K键盘)...

这是一个教训,也许也是给其他人的一个提示,要时刻留意案件中不存在的信息。

相关内容