Bug 19287
| Summary: | RHNSD should be replaced with cron tables | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Alan Cox <alan> |
| Component: | up2date | Assignee: | Adrian Likins <alikins> |
| Status: | CLOSED WONTFIX | QA Contact: | Jay Turner <jturner> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.1 | CC: | gafton, pbrown, srevivo |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2001-07-05 20:08:52 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Alan Cox
2000-10-17 21:39:06 UTC
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 immediately #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. 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
/etc/sysconfig/rhn.
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 |