On Fri, Jun 16, 2006 at 10:01:04AM -0700, Richard Elling wrote: > Darren Reed wrote: > >While I can understand that in principle, in reality, unless you are > >going to shut your system down because xntpd loses touch with > >a time server (and thus the system drifts), time (to an application) > >is generally not that important. It is nice to avoid repeated time > >stamps (through slowing down a system that has a time in the > >future) but if something really cares about this, it'll needs to do > >more than just rely on ntpdate being run. > > However, some very, very important applications get very, very upset > if time isn't correct or adjusts abruptly. > > There is an RFE lurking here: either a new service for ntpdate separate > from ntpd - or - a more sane way of handling ntpdate timeouts.
Can SMF represent dependencies where the dependee's failure to start does not stop the dependent from starting -- i.e., where the dependent waits for the other to start or go into maintenance before starting? Yes, I think splitting the ntp service may be good. At boot time one should want ntpdate to quickly step the clock (see its -b option). Subsequently, if ntpd dies one should not want ntpdate to be used at all in restarting ntpd. This argues for a transient service for ntpdate separate from ntpd, with the latter having an optional dependency on the former. Nico --
