[gentoo-user] Cron job email time off by one hour

[gentoo-user] Cron job email time off by one hour

[Tanstaafl]

Hi all,

Ok, I've googled and can't figure this out...

/etc/timezone is set to the correct timezone (EST5EDT)

Date command says the server time is correct.

Cron jobs run at the correct times.

EMails generated by cron have a time one hour in the past.

Looking at the email header shows the correct date/time stamps, but 
since Thunderbird by default uses the date/time header set by the 
client, it shows up as arriving an hour earlier than it actually did.

Anyone?

Re: [gentoo-user] Cron job email time off by one hour

[Alan McKinnon]

On 07/05/2013 16:31, Tanstaafl wrote:
> Hi all,
> 
> Ok, I've googled and can't figure this out...
> 
> /etc/timezone is set to the correct timezone (EST5EDT)
> 
> Date command says the server time is correct.
> 
> Cron jobs run at the correct times.
> 
> EMails generated by cron have a time one hour in the past.
> 
> Looking at the email header shows the correct date/time stamps, but
> since Thunderbird by default uses the date/time header set by the
> client, it shows up as arriving an hour earlier than it actually did.
> 
> Anyone?
> 

In the absence of info config from you other than the timezone, I'd say
Daylight Savings.

Recent cronds do new things with DST and timezones, depending on various
factors described in man cron. Perhaps you fell afoul of that.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Cron job email time off by one hour

[Tanstaafl]

On 2013-05-07 10:42 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 07/05/2013 16:31, Tanstaafl wrote:
>> Cron jobs run at the correct times.
>>
>> EMails generated by cron have a time one hour in the past.
>>
>> Looking at the email header shows the correct date/time stamps, but
>> since Thunderbird by default uses the date/time header set by the
>> client, it shows up as arriving an hour earlier than it actually did.

> In the absence of info config from you other than the timezone, I'd say
> Daylight Savings.

Thanks Alan,

I'll provide emerge --info at the end of this message, but not sure how 
that helps.

> Recent cronds do new things with DST and timezones, depending on various
> factors described in man cron. Perhaps you fell afoul of that.

Entirely probable, but googling hasn't helped reveal a solution.

One other thing - reading man cron, it says that /etc/crontab should be 
mode 0600... mine was 0644. I just changed it, but is there some way 
that could have caused it?

Any pointers/ideas? I can't be the only one to encounter this...

Thanks again...

**************** emerge --info

  # emerge --info
Portage 2.1.11.55 (default/linux/amd64/13.0, gcc-4.6.3, glibc-2.15-r3, 
3.3.8-gentoo x86_64)
=================================================================
System uname: 
Linux-3.3.8-gentoo-x86_64-AMD_Opteron-tm-_Processor_244-with-gentoo-2.1
KiB Mem:     2058236 total,     23500 free
KiB Swap:     506040 total,    322284 free
Timestamp of tree: Sat, 04 May 2013 16:00:01 +0000
ld GNU ld (GNU Binutils) 2.22
app-shells/bash:          4.2_p37
dev-lang/python:          2.7.3-r3, 3.1.5-r1, 3.2.3-r2
dev-util/cmake:           2.8.9
dev-util/pkgconfig:       0.28
sys-apps/baselayout:      2.1-r1
sys-apps/openrc:          0.11.8
sys-apps/sandbox:         2.5
sys-devel/autoconf:       2.69
sys-devel/automake:       1.7.9-r2, 1.9.6-r3, 1.10.3, 1.11.6, 1.12.6
sys-devel/binutils:       2.22-r1
sys-devel/gcc:            4.6.3
sys-devel/gcc-config:     1.7.3
sys-devel/libtool:        2.4-r1
sys-devel/make:           3.82-r4
sys-kernel/linux-headers: 3.7 (virtual/os-headers)
sys-libs/glibc:           2.15-r3
Repositories: gentoo gnustep sunrise ultrabug mbi-local
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=opteron -O2"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf 
/etc/gentoo-release /etc/php/apache2-php5.4/ext-active/ 
/etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.4/ext-active/ 
/etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=opteron -O2"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs buildpkg config-protect-if-modified 
distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch 
protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs 
unmerge-orphans userfetch"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo"
LANG="en_US.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j5"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times 
--compress --force --whole-file --delete --stats --human-readable 
--timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/var/lib/layman/gnustep /var/lib/layman/sunrise 
/var/lib/layman/ultrabug /usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="3dnow acl amd64 bash-completion berkdb bzip2 cli cracklib crypt 
curl cxx dovecot-sasl dri fam fortran gd gdbm gpm iconv mmx modules 
mudflap multilib ncurses nls nptl openmp pam pcre readline sasl session 
snmp sse sse2 ssl tcpd truetype unicode vhosts xml zlib" ABI_X86="64" 
ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci 
emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 
intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" 
ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug 
file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw 
multi null plug rate route share shm softvol" APACHE2_MODULES="actions 
alias auth_basic auth_digest authn_anon authn_dbd authn_dbm 
authn_default authn_file authz_dbm authz_default authz_groupfile 
authz_host authz_owner authz_user autoindex cache cgi dav dav_fs 
dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache 
filter headers ident imagemap include info log_config logio mem_cache 
mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect 
proxy_http rewrite setenvif so speling status unique_id userdir 
usertrack vhost_alias" APACHE2_MPMS="prefork" CALLIGRA_FEATURES="kexi 
words flow plan sheets stage tables krita karbon braindump author" 
CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool 
swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate 
evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom 
oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing 
tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" 
KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 
lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console 
presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" 
PHP_TARGETS="php5-4" PYTHON_SINGLE_TARGET="python2_7" 
PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby18 ruby19" 
USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 
radeon savage sis tdfx trident vesa via vmware dummy v4l" 
XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p 
iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark 
dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, 
PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, 
PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON

Re: [gentoo-user] Cron job email time off by one hour

[J. Roeleveld]

Tanstaafl <tanstaafl@libertytrek.org> wrote:

>Hi all,
>
>Ok, I've googled and can't figure this out...
>
>/etc/timezone is set to the correct timezone (EST5EDT)
>
>Date command says the server time is correct.
>
>Cron jobs run at the correct times.
>
>EMails generated by cron have a time one hour in the past.
>
>Looking at the email header shows the correct date/time stamps, but 
>since Thunderbird by default uses the date/time header set by the 
>client, it shows up as arriving an hour earlier than it actually did.
>
>Anyone?

Check the time in the headers of the email from the cronjob. It might be that this is caused by a different time (zone) of the mailserver or machine you are checking mail with.

--
Joost
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Cron job email time off by one hour

[Tanstaafl]

On 2013-05-07 11:43 AM, J. Roeleveld <joost@antarean.org> wrote:
> Tanstaafl<tanstaafl@libertytrek.org>  wrote:
>> Ok, I've googled and can't figure this out...
>>
>> /etc/timezone is set to the correct timezone (EST5EDT)
>>
>> Date command says the server time is correct.
>>
>> Cron jobs run at the correct times.
>>
>> EMails generated by cron have a time one hour in the past.
>>
>> Looking at the email header shows the correct date/time stamps, but
>> since Thunderbird by default uses the date/time header set by the
>> client, it shows up as arriving an hour earlier than it actually did.
>>
>> Anyone?

> Check the time in the headers of the email from the cronjob. It might
> be that this is caused by a different time (zone) of the mailserver
> or machine you are checking mail with.

Nope. It is our mail server, here in our office...

Also, I have rkhunter running on the same machine (job is in 
/etc/cron.daily, instead of the root crontab), which generates its own 
emails, and those have the correct time on them (header time matches 
what is in the log).

Re: [gentoo-user] Cron job email time off by one hour

[William Kenworthy]

On 08/05/13 00:47, Tanstaafl wrote:
> On 2013-05-07 11:43 AM, J. Roeleveld <joost@antarean.org> wrote:
>> Tanstaafl<tanstaafl@libertytrek.org>  wrote:
>>> Ok, I've googled and can't figure this out...
>>>
>>> /etc/timezone is set to the correct timezone (EST5EDT)
>>>
>>> Date command says the server time is correct.
>>>
>>> Cron jobs run at the correct times.
>>>
>>> EMails generated by cron have a time one hour in the past.
>>>
>>> Looking at the email header shows the correct date/time stamps, but
>>> since Thunderbird by default uses the date/time header set by the
>>> client, it shows up as arriving an hour earlier than it actually did.
>>>
>>> Anyone?
> 
>> Check the time in the headers of the email from the cronjob. It might
>> be that this is caused by a different time (zone) of the mailserver
>> or machine you are checking mail with.
> 
> Nope. It is our mail server, here in our office...
> 
> Also, I have rkhunter running on the same machine (job is in
> /etc/cron.daily, instead of the root crontab), which generates its own
> emails, and those have the correct time on them (header time matches
> what is in the log).
> 

Try googling "email header analysis" and drop the headers on one of the
sites for an analysis - helped me track down delays in a mailserver
chain in the past, but I cant remember which one I used.

BillK

Re: [gentoo-user] Cron job email time off by one hour

[Alan McKinnon]

On 07/05/2013 18:47, Tanstaafl wrote:
> On 2013-05-07 11:43 AM, J. Roeleveld <joost@antarean.org> wrote:
>> Tanstaafl<tanstaafl@libertytrek.org>  wrote:
>>> Ok, I've googled and can't figure this out...
>>>
>>> /etc/timezone is set to the correct timezone (EST5EDT)
>>>
>>> Date command says the server time is correct.
>>>
>>> Cron jobs run at the correct times.
>>>
>>> EMails generated by cron have a time one hour in the past.
>>>
>>> Looking at the email header shows the correct date/time stamps, but
>>> since Thunderbird by default uses the date/time header set by the
>>> client, it shows up as arriving an hour earlier than it actually did.
>>>
>>> Anyone?
> 
>> Check the time in the headers of the email from the cronjob. It might
>> be that this is caused by a different time (zone) of the mailserver
>> or machine you are checking mail with.
> 
> Nope. It is our mail server, here in our office...
> 
> Also, I have rkhunter running on the same machine (job is in
> /etc/cron.daily, instead of the root crontab), which generates its own
> emails, and those have the correct time on them (header time matches
> what is in the log).
> 


Are you saying that scripts which do mail correctly (i.e. by themselves)
work fine?

But when you rely on crond to send the mail by grabbing STDOUT, then the
time is wrong, and that this is consistent?

That would point to something with crond and would need a few tests such
as what happens with other crons from other users, what happens when you
downgrade cron and then test?

I'm assuming you use vixie-cron. Correct?



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Cron job email time off by one hour

[Tanstaafl]

On 2013-05-07 6:08 PM, William Kenworthy <billk@iinet.net.au> wrote:
> On 08/05/13 00:47, Tanstaafl wrote:
>> Also, I have rkhunter running on the same machine (job is in
>> /etc/cron.daily, instead of the root crontab), which generates its own
>> emails, and those have the correct time on them (header time matches
>> what is in the log).

> Try googling "email header analysis" and drop the headers on one of the
> sites for an analysis - helped me track down delays in a mailserver
> chain in the past, but I cant remember which one I used.

Thanks for trying, but that isn't the problem. The mail is delivered 
instantly - it's just the timestamp in the CLIENT-SET header is off by 
one hour.

Meaning... it shows up at 8:30am in my inbox, but the time displayed by 
my mua for that email is 7:30am. The headers containing the lines 
showing when it was actually received by the server also clearly show 
that it was generated and delivered at 8:30am, not 7:30am.

The same exact thing happens if the date/time on someone's computer is 
off...

Set your date/time on your computer to be 1 hour behind.

Using Thunderbird, send yourself an email.

Note that the email is displayed with the 1 hour old date/time, and is 
sorted/displayed in your inbox as if it was delivered 1 hour ago, even 
though you just saw it delivered moments ago, and the headers clearly 
reflect that it was really delivered moments ago.

Of course, any mua that uses the actual received date from the server 
will show it in the correct order, but Thunderbird doesn't do that by 
default.

Maybe that was clearer.

This is simply a cosmetic problem. Somehow, cron is setting a header 
with the time one hour in the past.