crontab execute correctly, but date in script fails

skylord · 04-07-2011, 06:04 PM

At the beginning of each month, /etc/crontab executes a job
at midnight to start a new Apache log file with the correct month
in the logfile name.

Job last ran April 1 at 00:00:01 according the /var/log/cron.
Here's my /etc/crontab entry.

# Apache log switch and restarting Apache
0 0 1 * * root /root/bin/apchlogchg.sh

Here's the apchlogchg.sh file...

#!/bin/bash
#
# Getting the "CURR"ent & "PREV"ious "Mon"th.
#
CURR=`date +%b%Y`
PREV=`date --date '1 month ago' +%b%Y`

If you were to echo $PREV, the results were "Feb2011".
Normally this script worked correct, but for April 1, it failed.

I have notice years past that having a job execute right a midnight,
sometimes fails when a "date" is involved. Could this be because of
the time change to DST in March?

We're running CentOS 5.5 x86_64.

Most of my servers came up with Feb2011, this April 1.

Any reason why the crontab begins on April 1, 00:00:01, but yet
the date command gets the wrong date? M

Thanks in advance.

colucix · 04-08-2011, 11:08 AM

Since the problem started from April most likely the DST is involved, but I cannot explain the reason. What if you try the -u option? What if you try the following from the command line?

Code:

date -d '20110401 1 month ago' +%b%Y

Anyway, since you're intersted in month and year, the following should be equivalent and might be a valid workaround:

Code:

date -d yesterday +%b%Y

Edit: according to the coreutils FAQ relative items in date strings may cause the result to end up at an undesired time. Such as at an invalid time due to a time change or in the same month instead of a different month and if you are working with months or years then it is more robust to operate at the middle of the month. They suggest to use a date at the middle of the month, e.g.

Code:

date --date="$(date +%Y-%m-15) -1 month" +%b%Y

Reference: http://www.gnu.org/software/coreutil...ing-right_002e

Reuti · 04-09-2011, 05:18 AM

For me it looks working, also on April 1st. What is your version of date --version? I get 6.12.

skylord · 04-12-2011, 03:03 PM

Colucix - Thanks for digging the FAQ up. The date command you provided is a bit over my head right now, but it's
beginning to sink in as to what you are doing.

I recall that 15 or so years ago on a SCO system, the crontab system would set the job off, but the date inside
the script would reveal a different time. I also recall the BIOS date was a few minutes apart from the OS date.
So, not fully understanding how Linux gets it's date, I'll use your suggestion for now.

This script has been working well for years. Just that this "time change" seems to have caused all of my scripts,
"be late" when getting the time. The crontab started the job on time, but the date command seems to have thought,
it was still in the previous month.

Thanks for your help.

skylord · 04-12-2011, 03:05 PM

Reuti - All servers have the same revision of 5.97.

Thanks for your reply.

Bodi · 04-15-2011, 01:20 PM

Quote:

@skylord

So, not fully understanding how Linux gets it's date.

Here is how it does it.

Quote:

The x86 and x86-64 computers that most often run Linux, as well as most other computers
of this general class, have two built-in clocks. The fi rst of these clocks, sometimes called
the hardware clock, maintains the time while the computer is turned off. When you boot
Linux, it reads the hardware clock and sets the software clock to the value it retrieves.
The software clock is what Linux uses for most purposes while it’s running.

The hardware clock works on Coordinated Universal Time (UTC).

Nominal Animal · 04-17-2011, 01:56 AM

Quote:

Originally Posted by skylord

This script has been working well for years. Just that this "time change" seems to have caused all of my scripts,
"be late" when getting the time.

Cron and your scripts may be using a different time zone. For example, when the scripts are run, they might have TZ set, in which case

Code:

date
env -u TZ date

give different "local times". Since service scripts like /etc/init.d/cron (which handles starting and stopping the cron service) are written to use the sh shell, the environment may differ if your scripts use e.g. bash or tcsh shell.

If you want to make sure your script is run at the first day of each month (which I think your script expects), you can do a simple loop to make sure the date has changed. This one is for bash, sh, dash or compatible shells:

Code:

while [ `date '+%Y%m'` -ne `date -d 'now + 18 hours' '+%Y%m'` ]; do sleep 60 ; done

The loop makes sure that if the month changes in the local time zone in the next 18 hours, it waits one minute at a time until the date has actually changed.

Hope this helps.