Red Hat Bugzilla – Bug 19287
RHNSD should be replaced with cron tables
Last modified: 2015-01-07 18:42:18 EST
Since rhnsd doesnt have its own entry I'll file it as close to that as
rhnsd wastes a process table slot, memory and is just doing part of the job
cron does. It needs replacing with crontab entries.
How do I guarantee that I will not have the whole world trying to connect to
our servers at the same second?
Your existing solution doesnt do this either. I can think of about 200 answers
#1 When the install script or the user reconfiguring the time interval
regenerats the crontab you
apply a small random factor of 0-(n-1) minutes generating the randomness via the
or via current time. In fact simply adding the low bits of the current clock
min/secs will do nicely
#2 The you dont care answer - a TCP connect is flow controlled. Actual connect
response is in
the control of the daemons the other end. I would assume the daemons have load
control anyway so we dont go boom after a major power cut brings everyones
machine back up the same minute all over new york or other more likely things
like we get attacked.
If we're not using rhnsd then we have to make sure that:
- we evenly distribute cronjobs across the population space
- we have good locking between different runs of rhn_check
- there is a quick and simple way to stop an rhn_check process
that mimics the "servoce rhnsd restart"
- it is very easy to disable this service.
I would eventually recommend keeping the rhnsd initscript around and
substitute the start and stop actions with crap that touches something in
On start) you delete all previous cron jobs and start a new one
On stop) you just remove the cron job.
All cron jobs use a common locking file. I can modify rhn_check to have a
lock file sitting around while it is running.
And when you think of it, this cronjob mumbo-jumbo is better/simpler/safer
than rhnsd how?
rhnsd is sitting around wasting machine resources all day. A proper cron job
add/remove script is needed for stuff anyway.
Possibly we should just leave the current piece of crap until we do the
honourable thing and burn the rhnsd daemon source code and switch to apt
That is the plan for now. I don't know about apt, maybe you can enlighten me,
but rhnsd doesn't eat that many resources and I favor its simplicity.
well, we more or less dealt with this in 7.1, no point in keeping it open