Bug 1656 - Crons and Red Hat 5.9
Crons and Red Hat 5.9
Status: CLOSED NOTABUG
Product: Red Hat Raw Hide
Classification: Retired
Component: crontabs (Show other bugs)
1.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Crutcher Dunnavant
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-03-21 17:59 EST by terminat
Modified: 2016-03-01 00:06 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-04-10 18:00:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description terminat 1999-03-21 17:59:51 EST
With Red Hat 5.9 (Starbuck) All crons are ran at boot.
That causes some problems on my system.  I add the crons in
rc.local so when it reboots it automatic.  But, then all
the crons run after crond comes up, cause crons to spawn
bad processes.  5.2 didn't do this.
Comment 1 Preston Brown 1999-03-23 13:57:59 EST
What sort of 'bad processes' get spawned?
Comment 2 terminat 1999-03-23 16:40:59 EST
For instance, I run a Linux Quake 2 Server.  So, I have rc.local
start the quake server.  Then I have multipile crons to reboot the
quake server, and check to see if it is running etc.  But, on reboot,
the quake server comes up in rc.local.  Then soon as crond comes up
all my crons are ran.  Thus cause my cron to reboot quake once a day
starts, kills the server, then the another script sees the server
isn't running so starts a quake server.  So, by the end of reboot, I
have like 6 quake servers running.  And with the same configs, and
crons I had in 5.2.  5.2 the crons where flawless.
Comment 3 Preston Brown 1999-03-24 11:01:59 EST
The new cron scheme is the right way to do things.  If you have a
laptop for instance, and it is off for some time, when it came back on
before, there would be cron jobs that had been "skipped."  This is a
bad thing.  Cron jobs that are scheduled to have been run should run
when the machine comes back up.  We understand that this is a policy
change on our part, but internal discussion as well as discussion with
the LSB group has lead to the change.

We suggest that you rewrite your local cron job.The new cron scheme is the right way to do things.  If you have a
laptop for instance, and it is off for some time, when it came back on
before, there would be cron jobs that had been "skipped."  This is a
bad thing.  Cron jobs that are scheduled to have been run should run
when the machine comes back up.  We understand that this is a policy
change on our part, but internal discussion as well as discussion with
the LSB group has lead to the change.

We suggest that you rewrite your local cron job.
Comment 4 terminat 1999-03-24 16:59:59 EST
I believe crons should run when scheduled to.  Not all on boot.  So,
if I schedule a cron to run once a day at 5 in the morning, I don't
want it to run when I reboot the machine at 2pm.
Comment 5 Preston Brown 1999-03-24 17:44:59 EST
I believe that I am wrong -- the cron behaviour has NOT been changed
to the new behaviour (the discussion is still pending).  The cron we
ship is the same that was included in 5.2, it has not changed.  I'm
not sure why you had the problem, but cron has not changed.  Perhaps
your time and date became skewed.
Comment 6 terminat 1999-03-24 18:27:59 EST
Ok I see.  So, 5.9 is still the same set up as the old 5.2 cron
setup.  See, I wrote this a bit too early, see, here's what I have in
rc.local, after the normal stuff this is gereneral too.

quake2 deathmatch
quake2 ctf
crontab /usr/util/cron
ipchains [my firewall stuff]
getdate

Now, here's the problem.  The bios date is correct, but linux reads
the date a day early.  So, like a co-admin where the box is located
reboots it when he can't figure out what's wrong (nice huh?) and the
logging routines for the deathmatch get messed up.  So, getdate, sets
the machine to the correct date from a different machine.  That were
the cron job get messed up.  But, to make a long story short, 5.9
looks awesome can't wait till 6.0.  We had to revert back to 5.2 at
the moment.  When I tried installing rpm's on 5.9 I got dependancies
that were wrong.  And the quake servers run fine until they get a lot
of traffic then die.  Don't know why.  nothing has changed.  I was
thinking the new lib's or dep's.
Comment 7 openshift-github-bot 2016-03-01 00:06:19 EST
Commit pushed to master at https://github.com/openshift/openshift-docs

https://github.com/openshift/openshift-docs/commit/a850e36e0483bf61f5b6accfb194ed08e1f7d03c
Merge pull request #1662 from bfallonf/issue_1656

Added note box about template location as per issue 1656

Note You need to log in before you can comment on or make changes to this bug.