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-nore...@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: u...@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 r...@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)
_______________________________________________
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
