Bug 4826
| Summary: | Timed regularly crashes system | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | swietanowski |
| Component: | timed | Assignee: | Preston Brown <pbrown> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.0 | CC: | swietanowski |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 1999-12-22 15:09:21 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: | |||
Here's a workaround for your timed problems: Try using xntpd, it handles time warps much more gracefully than timed. The hardest part about xntp is choosing a server. See the url or /usr/doc/xntp* for guidance there. Then on the local server, you will need to do chkdonfig --add xntpd echo your_xntp_server > /etc/ntp/step-tickers Add to /etc/ntp.conf server your_xntp_server If you can, enable multicast by commenting out multicastclient and adding broadcast as below: driftfile /etc/ntp/drift #multicastclient # listen on default 224.0.1.1 broadcast 224.0.1.1 key 65535 broadcastdelay 0.008 On each client, then do chkconfig --add xntpd echo the_local_server > /etc/ntp/step-tickers Restart the antpd daemons of local server and clients, wait 15 minutes, and look us "ntpq -p" to verify operation (an asterisk precedes the server that is currently being used for synchronization). If you do the above, all your clients will initially set the clock from your_local_server using ntpdate, and then receive synchronization from multicast packages. This problem appears resolved. Please reopen if I'm wrong. |
I set up a small cluster. The master makes NFS shares available. For normal operation of e.g. make on the NFS share, the time needs to be very tightly synchronized. I start timed as a master on the master PC and as a slave on each slave: (master) in /etc/rc.d/rc.local I added /usr/sbin/timed -M -n cluster.priv -t (slave) I created a script /etc/rc.d/init.d/timed which issues daemon timed -t and is called via appropriate symbolic links. After periods of long operation of the master system (days or even weeks), timed on master appears to go bonkers (a technical term). On different occasions I observed the following phenomena: (a) master system time slows down or even goes backwards (recently a few days in just a few minutes), (b) timed uses up a lot of processor time (50%) until it is killed, (happened once -- this is how I figured out who may be the culprit), (c) the system becomes unstable and requires reboot (always). As for (c) above, different things are happening on different occasions: (a) X started displaying something like a TV signal between the stations -- like modulated white noise, I had to kill it, kill timed and reboot (this was on the same occasion that timed was taking up 50% of CPU), (b) unrelated applications (e.g. F95 compiler) start behaving strangely, (c) other things which I can't recall now. The problem *may* be related to manual or automatic adjustments of time: once a day a cron process adjusts the time on the master with an external clock (much more accurate): /usr/bin/rdate -sp aurora