Re: Ctrl-c abort of dhclient during rc.d start aborts all network configuration

From: Robert Watson (rwatson_at_FreeBSD.org)
Date: 08/31/05

  • Next message: Brooks Davis: "Re: Ctrl-c abort of dhclient during rc.d start aborts all network configuration"
    Date: Wed, 31 Aug 2005 21:42:58 +0100 (BST)
    To: Brooks Davis <brooks@one-eyed-alien.net>
    
    

    On Wed, 31 Aug 2005, Brooks Davis wrote:

    > The wait should be 10 seconds plus some startup time.

    It seemed a bit longer, but maybe I was counting fast. I'll time it next
    time and see if there's more going on there.

    >> (1) It would be good to configure lo0 first.
    >
    > Interfaces are configured in order of index by default. If lo0 were
    > attached sooner, it would be configured sooner. I'm somewhat tempted to
    > change it from it's current (apparently bogus) position in the startup
    > process at SI_SUB_PROTO_IFATTACHDOMAIN to SI_SUB_INIT_IF/SI_ORDER_ANY
    > and push the l2com attachments from SI_ORDER_ANY to SI_ORDER_MIDDLE.
    > Strictly speaking I think lo(4) should be SI_SUB_PSEUDO, but moving it
    > up so it attached first makes some sense given how critical it is.
    >
    > Alternativly, one could add code to sort the result of "ifconfig -l" to
    > configure lo0 first.

    I wonder if we could sed out lo0 from the automatic list and just
    configure it first by fiat? While if_loop is in theory optional, it turns
    out not to be very practical using our default boot scripts (since many
    tools assume you can bind 0.0.0.0).

    >> (2) If a dhclient is ctrl-c'd, it would be nice if the rest of the network
    >> configuration continued.
    >
    > I don't see any code in the startup scripts that would cause them to
    > exit on failure so the issue is probalby that the signal is being
    > delivered to the /etc/rc.d/netif instance. I don't really know what the
    > solution to that is.

    Me neither. All I know is that I don't remember seeing this before.

    >> The printing of '.'s in dhclient is also a bit excessive.
    >
    > Hanging with no output seems even less unhelpful. :( Longer term I want
    > to get rid of syncronous calls to dhclient in the startup process, but I
    > haven't had time to work on it and IMO, it's a bit late in the game for
    > 6.0.

    I thought a bit about this, but concluded that we probably still have
    components that assume a one IP (no more, no less) world, and slide by now
    due to luck. A gradual conversion towards the assumptions of changing IPs
    has been happening over time (vis natd -dynamic), but perhaps we need to
    accelerate it some by forcing the issue in 7.x after 6.0 gets out the
    door?

    Robert N M Watson
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  • Next message: Brooks Davis: "Re: Ctrl-c abort of dhclient during rc.d start aborts all network configuration"

    Relevant Pages

    • Re: Starp up sequence
      ... >> RunServicesOnce ... >> User Profile Startup Folder ... >> the programs specified in the Computer Configuration setting just before ... >> AppInit_DLLs Registry value. ...
      (microsoft.public.windowsxp.customize)
    • RE: programs in tray
      ... Microsoft Windows XP by using the System Configuration utility ... Programs that are set to load during the startup process (these programs ... permanently deletes all restore points for the System Restore utility. ...
      (microsoft.public.windowsxp.customize)
    • Re: System Config.?
      ... >If I go to system configuration utility, service tab. ... Many applications that put items into the startup ...
      (microsoft.public.windowsxp.perform_maintain)
    • Re: When to use Environment Variables?
      ... > I'm developing an application that needs some configuration ... > setting to be loaded on startup. ... > I'd like most settings to be loaded one time at startup, ... a running program. ...
      (comp.os.linux.development.apps)