ntpd startup too early + hangs

Dan Williams dcbw at redhat.com
Wed Feb 2 17:31:45 UTC 2005

On Wed, 2005-02-02 at 12:15 -0500, Rik van Riel wrote:
> On Wed, 2 Feb 2005, Dan Williams wrote:
> > ntpd needs to be smarter about when it does & does not look for servers 
> > based on whether or not there's a connection.
> You could say that about every daemon we have, including
> eg. ypbind.  Alternatively, we could look at the impact
> that networkmanager and other new desktop programs have
> on the order in which the various services should be
> started up, and correct that.

Remember though, that just because NetworkManager has started doesn't
mean that you have an actual network connection, same as we've been
discussing, where you start up with the cable unplugged and the
'network' script times out.  So even if NetworkManager was started, the
daemons that depend on "network" would _still_ need to be aware of
whether or not there's a connection.

NetworkManager provides that information through a client library, but
that's written with glib right now (because its soooooo much easier to
use dbus with a binding rather than 500 lines of select() and associated
code to deal with threads and callbacks to the main thread).  The plan
is to write a non-glib, non-QT dependent client library in addition to
the glib-based one, so that system services will not have to link
against glib.  To figure out whether you're connected, you would then
simply do:

libnm_ctx *nm_ctx = libnm_init ();
switch (libnm_get_network_status (nm_ctx))
        have_network_connection = FALSE;

        have_network_connection = TRUE;
libnm_shutdown (nm_ctx);ctx);

This assumes that if NetworkManager is not running, you want the
previous behavior of simply assuming there is a network conneciton.
libnm should (and does in the current glib implementation) have a
callback interface to alert the application of network state changes
without having to poll.  The DBUS code runs in a separate thread and so
does not block anything the app is doing.


More information about the fedora-devel-list mailing list