Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 Oct 2014 13:38:31 -0400
From:      "John D. Hendrickson" <johnandsara2@cox.net>
To:        bugzilla-noreply@freebsd.org
Cc:        freebsd-bugs@FreeBSD.org
Subject:   Re: [Bug 194236] New: Hourly cron jobs running to early
Message-ID:  <543EB117.1060705@cox.net>
In-Reply-To: <0YXQ1p01Q2X408g01YXRfJ>
References:  <0YXQ1p01Q2X408g01YXRfJ>

next in thread | previous in thread | raw e-mail | index | archive | help
now keep in mind this note isn't about you in particular.  there's a 
massive problem with people hacking away with free permissions that end 
up causing others a life time of "upgrade failed" problems which is what 
i'm really getting at.

i'm not so sure your right - maybe cron is runnign same code as always 
for i386 (unless someone hacked it): and those people would be harmed by 
your hacking in changes

what your saying is in order to fix your computer that i386 you wish to 
damage anyone running a cron i386 who is NOT using amd64 (are you on a 
VAX?): which is wrong.

my guess is your pc is f'ed up (is it from china?), or that cron always 
ran at the end of the minute (under certain conditions) and the new code 
is f'ed up (ie, they "smartly" added better time resolution not 
realizing how cron ever ran to begin with) or that bsd, when i386 is in 
use falsely reports time: which again it's not a reason to hack cron 
it's a reason to firmly question who hacking IN the problem in bsd

in the past i've tried to make a tight system that relied on time before 
and canceled it: it's just too likely to go wrong (clock settings and 
updates, even the code handling, are too UNRELIABLE), too likely even 
when, say, two pc's are continually checked to stay even: even then it's 
too unreliable for file/data safety.

another thing i found is time resolution.  if you end up relying on a 
resolution that's shorter than what is really effective: you will end up 
either missing not once BUT ALWAYS or doubling your trigger (what i mean 
is you shouldn't intently write code that will become a race condition, 
only your pc has Hz configuration sharable with itself: if that, and 
your not a realtime HP unix: if that).  were NOT all running one amd. 
some regularly deal with various sites: some of which are UTC or not, 
some of which have correct time, others that are misconfigured.

ESPECIALLY if your talking about code distributed on many OSes and 
platforms: hacking in hardware time improvments that only work on some 
little pc's into cron to fix it on one computer (break it on another). 
bad, bad, bad

i don't mean to be stiff on you only

why doesn't my cron, which i compiled myself, on three different chips 
(and i used to compile 386 and distribute bins instead of recompiling 
everwhere, far easier)

why doesn't cron start on wrong times?

WAY WAY before filing a bug against cron and suggesting it's wrong and 
you'd like to edit it, you should be in user channel asking other 
questions, posting code you think may be responsible, and even posting A 
PATCH THAT FIXES IT

it's pretty pretentious to assume the old generation did not have 
elaborate plans, engineering degrees, and act in good faith and know 
exactly what they were doing.  i see a lot of disrespect and 
irresponsibility going on.  and i mean distro admins not bug posters.

(they've broken countless softwares and hardwares, incurred countless 
complaints: on stuff that was working fine, due to allowing their 
friends to hack anything for any reason.  i'm pissed personally.)


bugzilla-noreply@freebsd.org wrote:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194236
> 
>             Bug ID: 194236
>            Summary: Hourly cron jobs running to early
>            Product: Base System
>            Version: 10.0-RELEASE
>           Hardware: i386
>                 OS: Any
>             Status: Needs Triage
>           Severity: Affects Some People
>           Priority: ---
>          Component: bin
>           Assignee: freebsd-bugs@FreeBSD.org
>           Reporter: uffe@uffe.org
> 
> Seen on FreeBSD 10.0-RELEASE-p9 i386
> 
> After upgrading from 9.2-RELEASE-p12 (i386) to 10.0-RELEASE-p9 (i386)
> 
> cron runs hourly jobs up to a minutte too early.
> 
> This causes tasks like newsyslog to skip logrotation at the intended time -
> rotation will occour one hour delayed.
> 
> It has been discussed here:
> 
> http://lists.freebsd.org/pipermail/freebsd-stable/2014-June/079106.html
> 
> and is reported solved - but I'm seeing the problem on latest official patch
> level (10.0-RELEASE-p9)
> 
> Note: This seems to be an i386 problem only - as the equivalent amd64
> installations runs hourly cron at the exact time.
> 
> # uname -a
> FreeBSD asuseee 10.0-RELEASE-p9 FreeBSD 10.0-RELEASE-p9 #0: Mon Sep 15 14:32:29
> UTC 2014     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC 
> i386
> 
> 
> BEFORE upgrade (running 9.2-RELEASE-p12 (i386))
> 
> # cat /var/log/cron | grep newsyslog
> 
> Oct  5 13:00:00 smtpd /usr/sbin/cron[11742]: (root) CMD (newsyslog)
> Oct  5 14:00:00 smtpd /usr/sbin/cron[12271]: (root) CMD (newsyslog)
> Oct  5 15:00:00 smtpd /usr/sbin/cron[12995]: (root) CMD (newsyslog)
> Oct  5 16:00:00 smtpd /usr/sbin/cron[13595]: (root) CMD (newsyslog)
> Oct  5 17:00:00 smtpd /usr/sbin/cron[14654]: (root) CMD (newsyslog)
> Oct  5 18:00:00 smtpd /usr/sbin/cron[15614]: (root) CMD (newsyslog)
> Oct  5 19:00:00 smtpd /usr/sbin/cron[16319]: (root) CMD (newsyslog)
> Oct  5 20:00:00 smtpd /usr/sbin/cron[17884]: (root) CMD (newsyslog)
> Oct  5 21:00:00 smtpd /usr/sbin/cron[38642]: (root) CMD (newsyslog)
> Oct  6 00:00:00 smtpd /usr/sbin/cron[20850]: (root) CMD (newsyslog)
> 
> AFTER upgrade (running 10.0-RELEASE-p9 (i386))
> 
> # cat /var/log/cron | grep newsyslog
> 
> Oct  6 00:59:42 smtpd /usr/sbin/cron[7632]: (root) CMD (newsyslog)
> Oct  6 01:59:38 smtpd /usr/sbin/cron[6222]: (root) CMD (newsyslog)
> Oct  6 02:59:34 smtpd /usr/sbin/cron[7616]: (root) CMD (newsyslog)
> Oct  6 03:59:34 smtpd /usr/sbin/cron[9793]: (root) CMD (newsyslog)
> Oct  6 04:59:38 smtpd /usr/sbin/cron[10369]: (root) CMD (newsyslog)
> Oct  6 05:58:55 smtpd /usr/sbin/cron[10897]: (root) CMD (newsyslog)
> Oct  6 06:59:34 smtpd /usr/sbin/cron[11420]: (root) CMD (newsyslog)
> Oct  6 07:58:55 smtpd /usr/sbin/cron[11848]: (root) CMD (newsyslog)
> Oct  6 08:59:51 smtpd /usr/sbin/cron[12478]: (root) CMD (newsyslog)
> Oct  6 09:59:47 smtpd /usr/sbin/cron[12995]: (root) CMD (newsyslog)
> Oct  6 10:58:42 smtpd /usr/sbin/cron[13733]: (root) CMD (newsyslog)
> Oct  6 11:58:55 smtpd /usr/sbin/cron[14416]: (root) CMD (newsyslog)
> Oct  6 12:59:34 smtpd /usr/sbin/cron[15188]: (root) CMD (newsyslog)
> Oct  6 13:59:29 smtpd /usr/sbin/cron[15935]: (root) CMD (newsyslog)
> Oct  6 14:59:38 smtpd /usr/sbin/cron[16440]: (root) CMD (newsyslog)
> Oct  6 15:59:42 smtpd /usr/sbin/cron[17655]: (root) CMD (newsyslog)
> Oct  6 16:59:47 smtpd /usr/sbin/cron[18513]: (root) CMD (newsyslog)
> Oct  6 17:59:34 smtpd /usr/sbin/cron[19025]: (root) CMD (newsyslog)
> Oct  6 18:59:47 smtpd /usr/sbin/cron[19916]: (root) CMD (newsyslog)
> Oct  6 20:00:00 smtpd /usr/sbin/cron[20624]: (root) CMD (newsyslog)
> Oct  6 20:59:29 smtpd /usr/sbin/cron[21680]: (root) CMD (newsyslog)
> Oct  6 21:59:34 smtpd /usr/sbin/cron[22962]: (root) CMD (newsyslog)
> Oct  6 22:59:38 smtpd /usr/sbin/cron[23582]: (root) CMD (newsyslog)
> Oct  6 23:59:47 smtpd /usr/sbin/cron[24275]: (root) CMD (newsyslog)
> Oct  7 00:59:47 smtpd /usr/sbin/cron[24988]: (root) CMD (newsyslog)
> Oct  7 01:59:34 smtpd /usr/sbin/cron[25758]: (root) CMD (newsyslog)
> Oct  7 02:59:21 smtpd /usr/sbin/cron[26291]: (root) CMD (newsyslog)
> Oct  7 03:59:47 smtpd /usr/sbin/cron[28272]: (root) CMD (newsyslog)
> Oct  7 05:00:00 smtpd /usr/sbin/cron[28715]: (root) CMD (newsyslog)
> Oct  7 05:59:12 smtpd /usr/sbin/cron[29252]: (root) CMD (newsyslog)
> Oct  7 06:58:46 smtpd /usr/sbin/cron[29821]: (root) CMD (newsyslog)
> Oct  7 07:59:51 smtpd /usr/sbin/cron[30357]: (root) CMD (newsyslog)
> Oct  7 08:59:34 smtpd /usr/sbin/cron[31222]: (root) CMD (newsyslog)
> Oct  7 09:59:51 smtpd /usr/sbin/cron[31980]: (root) CMD (newsyslog)
> Oct  7 10:59:47 smtpd /usr/sbin/cron[32710]: (root) CMD (newsyslog)
> Oct  7 11:59:51 smtpd /usr/sbin/cron[33278]: (root) CMD (newsyslog)
> Oct  7 12:59:55 smtpd /usr/sbin/cron[33832]: (root) CMD (newsyslog)
> Oct  7 13:59:34 smtpd /usr/sbin/cron[34276]: (root) CMD (newsyslog)
> Oct  7 14:59:51 smtpd /usr/sbin/cron[34833]: (root) CMD (newsyslog)
> Oct  7 15:59:21 smtpd /usr/sbin/cron[35492]: (root) CMD (newsyslog)
> Oct  7 16:58:42 smtpd /usr/sbin/cron[36213]: (root) CMD (newsyslog)
> Oct  7 17:59:42 smtpd /usr/sbin/cron[37072]: (root) CMD (newsyslog)
> Oct  7 18:59:47 smtpd /usr/sbin/cron[37958]: (root) CMD (newsyslog)
> Oct  7 19:59:47 smtpd /usr/sbin/cron[38780]: (root) CMD (newsyslog)
> Oct  7 20:59:12 smtpd /usr/sbin/cron[39330]: (root) CMD (newsyslog)
> Oct  7 21:58:55 smtpd /usr/sbin/cron[40561]: (root) CMD (newsyslog)
> Oct  7 22:59:55 smtpd /usr/sbin/cron[41477]: (root) CMD (newsyslog)
> Oct  7 23:59:25 smtpd /usr/sbin/cron[47064]: (root) CMD (newsyslog)
> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?543EB117.1060705>