Re: Network services started before NIC UP.
On Wed, Dec 11, 2013 at 12:12:14AM CET, Bob Proulx <bob@proulx.com> said:
> Erwan David wrote:
> > I have a problem that services are started on a server I manage before
> > link is UP. This leads to some services failing, or not bound to every
> > addresses :
>
> Please say what release track you are using? Unstable, Testing, Stable?
I use testing.
> Please say whether you are using parallel boot or not.
I use the stndard testing sysVrc with "make style parrallel boot".
> Running
> 'insserv' manually and noting any errors and reporting them would be
> very useful.
>
> # insserv -v
> insserv: creating .depend.boot
> insserv: creating .depend.start
> insserv: creating .depend.stop
No error.
> > You can see that ntpdate is started before network is ready. What is
> > more annoying is that I get an IPv6 prefix through dhcpv6 prefix
> > delegation, and even though the logs do not appear here, it seems the
> > dhcpv6 request is sent (by dibbler-client) before NIc is UP, which leads
> > to my prefix not being routed to my server.
> >
> > Against which package should I report a bug, and is there a workaround
> > for next reboot ?
>
> The 'ntpdate' package is obsolete. You should remove it and let ntpd
> do the task itself. I think that is very likely the problem. I think
> you have an old ntpdate package installed when it should have been
> removed. I think this old package is one (of possibly several) that
> is causing the boot sequence to be legacy mode instead of the current
> parallel mode controlled by insserv. I think because of those things
> the boot order is unhappy on your system.
I maay remove ntpdate, but other services are touched by the
problem. Most annoyings are the dibbler dhcpv6 client (which does not
get any answer) and NSD name server (which binds to the IPv4 address
but not to the IUPv6 one which is at that time not yet configured).
Reply to: