[...] > I'm not sure I agree that restart is the right thing > -- rereading the > configuration file etc. might have unanticipated side > effects. What is > necessary is to put the server into some kind of "get > your clocks in > order quickly, because they are probably wrong" mode. [...]
Back in the day when suspend/resume worked on a Sun Blade 100, I had written my own program to take certain actions on receipt of SIGTHAW, one of those being restarting xntpd. Perhaps I was very fortunate, but that never caused any problems. As long as /etc/inet/ntp.conf is a local file, and esp. given the previously mentioned changes about retrying on name services problems, only one problem occurs to me: xntpd (and I assume the new ntpd) runs in the RT scheduling class, and uses mlock() or mlockall(). That has been said to be mutually exclusive with some other actions, like fssnap_ufs(1m). Therefore, if [x]ntpd is restarted, there is a race condition in that some such mutually exclusive activity could be started between when the old instance of [x]ntpd is killed and the new one spawned, precluding the new one from runnning properly. Being able to tell an existing instance to reinitialize itself could preclude that. -- This message posted from opensolaris.org
