Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 19287 - RHNSD should be replaced with cron tables
RHNSD should be replaced with cron tables
Product: Red Hat Linux
Classification: Retired
Component: up2date (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Jay Turner
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2000-10-17 17:39 EDT by Alan Cox
Modified: 2015-01-07 18:42 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-07-05 16:08:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alan Cox 2000-10-17 17:39:06 EDT
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.
Comment 1 Cristian Gafton 2000-10-17 18:55:49 EDT
How do I guarantee that I will not have the whole world trying to connect to
our servers at the same second?
Comment 2 Alan Cox 2000-10-18 11:17:31 EDT
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
random device
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.

Comment 3 Cristian Gafton 2001-02-19 19:23:52 EST
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?
Comment 4 Alan Cox 2001-02-19 19:39:54 EST
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
Comment 5 Cristian Gafton 2001-02-19 19:53:25 EST
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.
Comment 6 Cristian Gafton 2001-07-25 20:52:01 EDT
well, we more or less dealt with this in 7.1, no point in keeping it open

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