Linux & Time - Time is what we want most, what we use worst.

mail

Why isn't my /etc/cron.hourly/jobName job executed ?

Situation

I have : ... but the script is still not executed

Details

grep hourly /etc/crontab 
17 * * * *	root	cd / && run-parts --report /etc/cron.hourly

Every hour, at xx:17, CRON fires run-parts to run anything executable within /etc/cron.hourly.

run-parts is a little picky and will purely ignore files with names containing "forbidden" characters. The dot . is on the blacklist
Full list and details : man run-parts

Solution

  1. Rename the script (or symlink) that will be passed to run-parts so that it has no "forbidden" character anymore.
  2. Check by listing everything run-parts is willing to execute : run-parts --list /etc/cron.hourly
mail

What's the difference between @hourly crontab jobs and /etc/cron.hourly/jobName jobs ?

@hourly crontab jobs /etc/cron.hourly/jobName jobs
Ownership Each user has a personal crontab, so such jobs can be set by everybody Requires write access in /etc/cron.hourly/, so root only
Execution time @hourly is an alias for 0 * * * * : commands are started at hh:00
(details : man 5 crontab) 		grep hourly /etc/crontab 
17 * * * *	root	cd / && run-parts --report /etc/cron.hourly
By default : at hh:17 on Debian Jessie
mail

When are executed the @hourly / @daily / @weekly / @monthly / @yearly CRON jobs ?

cat /etc/crontab

# m h dom mon dow	user	command
17 * * * *	root	cd / && run-parts --report /etc/cron.hourly					this is executed as-is
25 6 * * *	root	test -x /usr/sbin/anacron || (cd / && run-parts --report /etc/cron.daily)	this is executed only if anacron is not installed
47 6 * * 7	root	test -x /usr/sbin/anacron || (cd / && run-parts --report /etc/cron.weekly)	this is executed only if anacron is not installed
52 6 1 * *	root	test -x /usr/sbin/anacron || (cd / && run-parts --report /etc/cron.monthly)	this is executed only if anacron is not installed

If anacron is installed, cron delegates the running of aliased jobs :
grep 'anacron start' /etc/cron.d/anacron

30 7 * * *	root	test -x /etc/init.d/anacron && /usr/sbin/invoke-rc.d anacron start >/dev/null
Every day, at 7:30AM, cron fires anacron (which is not a daemon since it dies after doing its daily duty). The /etc/init.d/anacron script is used to :
  1. run anacron once at boot so that it can catch up with missed jobs
  2. let cron start anacron every day at the specified time

anacron itself is controlled via /etc/anacrontab :
cat /etc/anacrontab

# These replace cron's entries
1		5	cron.daily	run-parts - -report /etc/cron.daily
7		10	cron.weekly	run-parts - -report /etc/cron.weekly
@monthly	15	cron.monthly	run-parts - -report /etc/cron.monthly

So, every day at 7:30AM, cron wakes anacron up. anacron waits an extra 5 minutes, then starts daily jobs : it's 7:35AM !

mail

Timezones & daylight saving changes

Timezones

It is fairly easy to get the current time of any zone. Time zones are listed in /usr/share/zoneinfo :

  • /usr/share/zoneinfo/Africa/Bamako
  • /usr/share/zoneinfo/America/New_York
  • /usr/share/zoneinfo/Asia/Tokyo
  • /usr/share/zoneinfo/Australia/Canberra
  • /usr/share/zoneinfo/Europe/Paris
  • /usr/share/zoneinfo/Japan
  • /usr/share/zoneinfo/Mexico/BajaNorte
  • ...

The current timezone is defined in :

  • Red Hatoids : /etc/sysconfig/clock
  • Debianoids : /etc/timezone
while /etc/localtime is :
  • Red Hatoids : a symlink to the current timezone file
  • Debianoids : a copy of the original timezone data file. Check it with : diff /etc/localtime /usr/share/zoneinfo/$(cat /etc/timezone)

To change the configured timezone (source) :

dpkg-reconfigure tzdata

To get the current date and time of any zone :

zdump Europe/Paris; zdump Japan; zdump Asia/Tokyo

Europe/Paris	Tue Jan 19 10:10:57 2016 CET
Japan		Tue Jan 19 18:10:57 2016 JST
Asia/Tokyo	Tue Jan 19 18:10:57 2016 JST

If you specify a non-existing timezone, this will return the current local time :

zdump Europe/Paris; zdump maison; zdump 127.0.0.1
Europe/Paris	Tue Jan 19 11:11:01 2016 CET
maison		Tue Jan 19 10:11:01 2016 maison
127.0.0.1	Tue Jan 19 10:11:01 2016
There is a 1-hour difference, don't know why

Daylight saving changes :

A combination of verbose mode and grep can list daylight saving changes :

zdump -v Europe/Paris | grep 201[56]

Europe/Paris	Sun Mar 29 00:59:59 2015 UTC = Sun Mar 29 01:59:59 2015 CET isdst=0 gmtoff=3600
Europe/Paris	Sun Mar 29 01:00:00 2015 UTC = Sun Mar 29 03:00:00 2015 CEST isdst=1 gmtoff=7200
Europe/Paris	Sun Oct 25 00:59:59 2015 UTC = Sun Oct 25 02:59:59 2015 CEST isdst=1 gmtoff=7200
Europe/Paris	Sun Oct 25 01:00:00 2015 UTC = Sun Oct 25 02:00:00 2015 CET isdst=0 gmtoff=3600
Europe/Paris	Sun Mar 27 00:59:59 2016 UTC = Sun Mar 27 01:59:59 2016 CET isdst=0 gmtoff=3600
Europe/Paris	Sun Mar 27 01:00:00 2016 UTC = Sun Mar 27 03:00:00 2016 CEST isdst=1 gmtoff=7200
Europe/Paris	Sun Oct 30 00:59:59 2016 UTC = Sun Oct 30 02:59:59 2016 CEST isdst=1 gmtoff=7200
Europe/Paris	Sun Oct 30 01:00:00 2016 UTC = Sun Oct 30 02:00:00 2016 CET isdst=0 gmtoff=3600
mail

atime / ctime / mtime

Timestamp Usage Changes when ...
atime file access time the file is
see also : atime and mount options
ctime inode change time
  • the metadata of the file (owner, permissions, ...) changes
  • when the file is written to
  • touched (not directly but as a consequence of updating mtime)
mtime file modification time the file is
  • written to. Whenever mtime changes, so does ctime
  • touched

atime and mount options :

When filesystems are on non-spinning drives but rather on SSDs, flash cards or memory cards, it is very common to use the noatime mount option. In such case, the atime value may not be updated as expected :
echo 'hello world' > myTestFile; stat --format='%x' myTestFile; sleep 1; cat myTestFile 1>/dev/null; stat --format='%x' myTestFile; rm myTestFile
  • on a filesystem mounted with relatime : 
    2021-02-04 15:20:21.868392531 +0100
2021-02-04 15:20:22.868392531 +0100
  • on a filesystem mounted with noatime : 
    2021-02-04 15:20:36.780392531 +0100
2021-02-04 15:20:36.780392531 +0100