I recently encountered a puzzling situation on Ubuntu 10.04 where cron jobs placed in /etc/cron.d wouldn't execute unless I manually edited the file. Here's what I discovered and how to properly handle cron job management on older Ubuntu systems.

The system exhibits these symptoms:

• New files in /etc/cron.d are ignored by cron
• Existing files only trigger execution after modification
• Standard reload commands (service cron restart, touch) have no effect
• No relevant entries appear in /var/log/syslog

After digging through the cron source code and documentation, I found that Ubuntu 10.04's cron implementation (Vixie cron) has a particular behavior regarding inotify watches. The daemon doesn't properly detect newly created files in /etc/cron.d due to how inotify watches are established on directories.

Here are three working approaches:

1. Force a Full Cron Reload

The most reliable method is sending a SIGHUP to the cron daemon:

sudo killall -HUP cron

2. Use the Proper Service Command

While restart and reload don't work, this command does:

sudo /etc/init.d/cron restart

3. Modify the Cron File Format

Add a comment line with a special format that forces cron to re-read the file:

# Special header to force cron re-read
* * * * * root echo "Force cron to re-read this file" > /dev/null
# Your actual cron job below
* * * * * www-data if [ -f /usr/local/bin/thing ]; then exec /usr/bin/php /usr/local/bin/thing mode:prod -a 14 -d >> /var/log/thing/mything.log 2>&1; else echo date +'[\%D \%T]' "Thing not deployed. Command not run" >> /var/log/thing/mything.log; fi &

To avoid this issue completely, consider:

sudo apt-get update
sudo apt-get install cron

This will upgrade to a newer version of cron that properly handles inotify events.

To verify if your cron job is being recognized:

sudo grep CRON /var/log/syslog | tail -20

Check for entries containing your job's command or the filename.

When working with Ubuntu 10.04's cron system, I encountered a particularly stubborn issue: newly added files in /etc/cron.d wouldn't execute until manually edited. The setup appeared correct - proper permissions, valid syntax, and a trailing newline - yet the jobs remained dormant.

The cron daemon in Ubuntu 10.04 (Vixie Cron) has a specific behavior regarding file changes:

# Original cron entry that wasn't triggering
* * * * * www-data if [ -f /usr/local/bin/thing ]; then exec /usr/bin/php /usr/local/bin/thing mode:prod -a 14 -d >> /var/log/thing/mything.log 2>&1; else echo date +'[\\%D \\%T]' \"Thing not deployed. Command not run\" >> /var/log/thing/mything.log; fi &

After extensive testing, I found these reliable methods to make cron recognize new files:

1. Full service restart (most reliable):

   sudo service cron restart

2. Alternative approach (when restart isn't possible):

   sudo touch /etc/crontab
   sudo /etc/init.d/cron reload

To confirm cron is processing your file:

# Check syslog for cron activity
grep CRON /var/log/syslog

# Verify file permissions (should be 644)
ls -l /etc/cron.d/runscript

# Confirm owner (should be root)
stat -c "%U" /etc/cron.d/runscript

Best practices for reliable cron jobs in Ubuntu 10.04:

• Always include a trailing newline in cron files
• Set explicit PATH in your cron job if needed
• Consider using flock for job locking instead of custom solutions
• For complex scripts, call a separate shell script rather than putting logic in the cron line

Here's a more maintainable version of the original cron job:

# /etc/cron.d/runscript
* * * * * www-data /usr/local/bin/run_thing_wrapper.sh

# /usr/local/bin/run_thing_wrapper.sh
#!/bin/bash
LOG_FILE="/var/log/thing/mything.log"
TIMESTAMP=$(date +'[%D %T]')

if [ -f /usr/local/bin/thing ]; then
    /usr/bin/php /usr/local/bin/thing mode:prod -a 14 -d >> "$LOG_FILE" 2>&1 &
else
    echo "$TIMESTAMP Thing not deployed. Command not run" >> "$LOG_FILE"
fi