I have a server that I am hosting at home using a residential ISP that issues public IP addresses via DHCP--that is to say, I don't always get the same IP back when my DCHP lease renews. I created a bash script to check whether my public IP has changed, and to e-mail me the new IP address if it has changed. The "current" IP is stored in a text file in my home directory that is globally readable and writeable. I'd like to run this hourly, but I can't seem to get cron to run any jobs for me. The script runs without any issues.

I've reviewed previous questions and I don't think there are issues with file permissions or output handling problems. The file/job just never shows up in /var/log/syslog.



System Details (uname -a): Linux jasonbourne 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) x86_64 GNU/Linux

cron details (apt info cron): Version: 3.0pl1-137

bash details (apt info bash): Version: 5.1-2+deb11u1

The Bash Script:


#known (current) IP
current_ip=`cat /home/jasonbourne/.current_ip`

#check for actual IP
check_ip=`dig -4 +short myip.opendns.com @resolver1.opendns.com`

if [ $check_ip != $current_ip ]
    message="`hostname`'s IP address changed from $current_ip to $check_ip on `date +%D` at `date +%T`"
    email="[email protected]"
    subject="`hostname` IP address change!"
    echo $message | mail -r $email -s "$subject" $email
    echo $check_ip > /home/jasonbourne/.current_ip

The script and my current IP have appropriate permissions:

jasonbourne@debian:~$ ls -la /usr/bin/public-ip-monitor.sh
-rwxr-xr-x 1 root root 873 Dec 28 20:14 /usr/bin/public-ip-monitor.sh
jasonbourne@debian:~$ ls -la /home/jasonbourne/.current_ip
-rw-rw-rw- 1 jasonbourne jasonbourne 15 Dec 28 21:28 /home/jasonbourne/.current_ip

The crontab and cron.time Attempts:

The cron service is running just fine:

jasonbourne@debian:~$ 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 Wed 2022-12-28 00:32:37 EST; 21h ago
       Docs: man:cron(8)
   Main PID: 14242 (cron)
      Tasks: 1 (limit: 4583)
     Memory: 1.0M
        CPU: 3.949s
     CGroup: /system.slice/cron.service
             └─14242 /usr/sbin/cron -f

I've set my user crontab with crontab -e and I've tried 0 * * * * /usr/bin/public-ip-monitor.sh and @hourly /usr/bin/public-ip-monitor.sh. I've also placed the script in /etc/cron.hourly.

  • 1
    what does /var/log/syslog say? are there any cron logs?
    – Alex
    Commented Dec 29, 2022 at 7:21
  • @Alex - plenty of cron activity. There's some sendmail activity every 20 minutes, and the hourly jobs look like they should be getting run, e.g.: Dec 28 20:17:01 debian CRON[38218]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly). While testing /etc/cron.hourly (typo in OP, will fix), I left the script in the directory overnight but it never showed up in the logs. Commented Dec 29, 2022 at 8:16
  • 1
    I'd expect some messages from cron if it failed to execute the script. I'm also curious if you've enabled SE Linux; that could prevent execution if things aren't set up properly.
    – Jeff Schaller
    Commented Dec 29, 2022 at 17:45
  • 1
    I see from askubuntu.com/a/607974/619216 that Debian wants a specific filename format for scripts under /etc/cron.daily/; can you show the filename you used for that directory?
    – Jeff Schaller
    Commented Dec 29, 2022 at 19:04
  • 1
    @JeffSchaller, I re-read the question you posted and realized that . is not in the character space. Aha! I will test and report back. Commented Dec 29, 2022 at 20:21

1 Answer 1


The reason that /etc/cron.hourly/public-ip-monitor.sh didn't work is because the hourly cron entries are initiated via run-parts in the /etc/crontab file:

01 * * * * root cd / && run-parts --report /etc/cron.hourly

run-parts has certain rules about what it runs:

run-parts runs all the executable files named within constraints described below, found in directory directory.

If neither the --lsbsysinit option nor the --regex option is given then the names must consist entirely of ASCII upper- and lower-case letters, ASCII digits, ASCII underscores, and ASCII minus-hyphens.

As a result, a file that's named with a .sh extension will not be run.

Hat tip to kenorb's AU answer for pointing me in this direction.

You must log in to answer this question.

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