1

I've been encountered a strange phenomena.

I've been messing with cron, so it runs a script called startup.sh, which it does.

I used the command sudo crontab -e and then entered the following:

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

First I wrote the script to send an email, but later I rewrote it to send a message instead. However, when restarting the server, nothing happened.

Then I checked the status of cron, and was surprised that it had run the old script, which now didn't exist anymore. Is there some kind of cron cache?

Here I'm checking the status:

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

It tried to run the mail script, which don't exist anymore, and it failed (worked before, but that's not the issue)

Then I checked the script file:

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

#!/bin/bash

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

It was the new script, so where did cron run the other (now rewritten script) from?

I've of course restarted Linux, I've even tried to clear the cache, but it don't work..

.. So now I'm confused... (More than normal). Anybody that knows anything as about this?

Running on Ubuntu 18.04.3lts mini

17
  • 1
    Please edit your question and show us the crontab you are using. We need to see how cron is running the script. Also, it's always a good idea to tell us what operating system you are using since there can be differences in implementation.
    – terdon
    Jan 21, 2020 at 12:30
  • I didn't know there was more than one crontab, how do I know which one?
    – JoBe
    Jan 21, 2020 at 13:28
  • Well, how did you set it up? We need to see the crontab. You must have told cron to run your script somehow right? How? Show us the cron line. And yes, there are many crontabs. Each user has their own, and then you have /etc/crontab which is run by root.
    – terdon
    Jan 21, 2020 at 13:35
  • I just used sudo crontab -e
    – JoBe
    Jan 21, 2020 at 13:35
  • 2
    So you are using root's crontab for some reason. OK, but can you please show us the crontab?
    – terdon
    Jan 21, 2020 at 13:36

1 Answer 1

0

This is a classic "chase your own tail" issue.

If a cron job strikes on an error, cron will send an email from the user account it's current running on, to the email specified in the current mail Configuration on the system.

Since the first script was notification via email, I assumed (a faulty assumption) that cron was running some strange "ghost copy" of the script, but it was just doing it's job.

It was @kusalananda that got me on the right track.

What I find curious, and the reason for me to write this as an answer, is that cron never said that anything was wrong with the new script, except that it couldn't send an email. A little moment 22, where the focus was placed on the wrong issue.

This is of course not the optimal answer, but this time it was a sbk error (Stupid Behind Keyboard)...

So a lesson learnt, and maybe a tips to others, to always keep an eye open for the information that isn't present in a case..

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .