cron not picking up crontab in /etc/cron.d without specific conditions

6/15/2017

I'm running Ubuntu 14.04.5 in a container in kubernetes. I'm running cron (successfully) however it's not picking up my crontab unless the minutes field is * or some variation such as */45. Anyone know why this is? The test for this has been to echo to the log and so far it's consistently proving to work that way. /etc/cron.d/crontab file looks like this:

# Run my command
SHELL=/bin/bash
*/47 17 * * * root echo "`date`: About to run!" >> /var/log/cron.log 2>&1
#

If I change this to what I think is standard notation it doesn't work ex:

# Run my command
SHELL=/bin/bash
47 17 * * * root echo "`date`: About to run!" >> /var/log/cron.log 2>&1
#

Is there something I'm missing that is causing this behavior? Note that I have the user specified, I have a trailing new line, and it's in the proper notation. I've also simplified to have just the echo and the same result appears to happen. Any information would be appreciated. I'm baffled by this.

-- M Simoneau
bash
cron
kubernetes

1 Answer

6/15/2017

Seems to be a bug in Ubuntu. Assuming that Ubuntu retains the same cron that is in Debian, (it should, but why would canonical do that?) you should be able to use a standard format.

Looking at the code, "*" means a range of "first to last" for whatever the available range is. There are a series of 'if' statements that try to determine the entries, and if certain conditions evaluate a certain way, it will return EOF and bail out on you.

So, */47 in the minute section means 1-59 step (every) 47th minute. This takes one code path, which is AFTER the code path that should say: "at minute 47".

So, if your step path ("/47") is evaluating when the regular one is not evaluating, then it's skipping that code path for some reason.

I've had a lot of weird problems with Ubuntu (like this). One of the reasons we run Debian nearly exclusively on servers.

-- DrDamnit
Source: StackOverflow