On Tue, Aug 28, 2007 at 08:39:29AM -0400, Brian Utterback wrote: > Ah, the hazards of being in different timezones; so much goes on while > I am away.
:/ > To answer a few things brought up during this thread: > > I already considered placing the daemon in DEGRADED state. Alas, > DEGRADED is not yet implemented in SMF. A pity, since it would have > been exactly what was needed. Er, it sure is implemented. Dependencies on that state are not possible. Hmmm, er, hmmm, no, it doesn't seem to be implemented, or something else is wrong (but it is documented): - I can "svcadm mark degraded ..." - svcs won't show it as such - svcadm clear ... complains > As far as letting daemons query the "quality" of the time, this is > a bit tricky. But it is doable. > Applications that care fall into a few categories. > The first is applications that insist on monotonically increasing time > without steps. Yup. And SMF dependencies such as they are are more than sufficient to cover these because this is a binary dependency: either the system has reached the point in boot where the clock will be guaranteed to run monotonically without skipping seconds, or it isn't. (Ignore the possibility of subsequent drift so far out of sync that an admin might manually set the date and skip time, or worse, replay time.) I assume that the desktop apps and login system don't fall into this category -- that only some unbundled and/or 3rd party apps would. The other category presents a different problem: analog dependencies. I imagine that all apps in the second category also fall into the first. But not all such apps are parts of "services" in the SMF sense. Things like the NFS client, ssh, telnet, etcetera, that can use Kerberos V are clients, and except for the NFS client, there's no associate SMF service. > The second category of application cares about the accuracy of the > clock. How can it find this out? The ntpd and xntpd always adjust the > clock to match their best idea of the current time. There is no way to > determine how close that is to the real time without an independent > time source. Time is always relative to something. Yes, but that is just what NTP does: it tries to sync time to other ("independent") time sources. And NTP does estimate error (and drift, when no time sources are available). I understand that it can't always. Nico --