# udev-200, ntp-client fails before network is up

## ecko

I just upgraded to udev-200. The boot sequence is now faster, as it does not seem to wait anymore for for an answer from the server (dhcp) to go to the next step. So while the system is slowly acquiring carrier, asking for a lease, etc. ntp-client is already running, and fails to start on dns errors (of course network is not up yet). Then X starts, but time is not set.

I tried to add /etc/init.d/ntp-client restart in /etc/local.d/baselayout.start so that it would try again, but this is too early as well. I could add a sleep 5 to make sure it waits enough time, but this is not very robust to network conditions, and not elegant either. Is there a better solution ?

Thanks, ecko.

----------

## darkphader

I noticed this as well. Seems the init scripts are confused as to when "net" is up and running - the ntp-client init script clearly states "after net". Prolly best to wait until the devs have sorted out the persistent net naming stuff.

----------

## SamuliSuominen

I believe I've seen something similar happening to me once on one system. Editing rc_hotplug= line in /etc/rc.conf helped that system. Perhaps it's worth a shot to try disable

hotplugging for the interface(s), like with "!net.*"

 *Quote:*   

> 
> 
> # rc_hotplug is a list of services that we allow to be hotplugged.
> 
> # By default we do not allow hotplugging.
> ...

 

This is related to the Gentoo specific /lib/udev/rules.d/90-network.rules and /lib/udev/net.sh. However I'm not sure yet.

----------

## ecko

 *ssuominen wrote:*   

> Editing rc_hotplug= line in /etc/rc.conf helped that system. Perhaps it's worth a shot to try disable
> 
> hotplugging for the interface(s), like with "!net.*"
> 
> 

 

I just tried, it did not seem to help.

So for now I created a file /etc/local.d/wait-network.start

```
#!/bin/bash

test_address="8.8.8.8"

timeout=20

exitloop="0"

i=0

success=1

while [ "${exitloop}" -le "0" ] ; do

        exitloop=`ping -c 1 -W 1 ${test_address} 2>/dev/null | grep -c "1 received"`

        i=$(( ${i} + 1 ))

        if [ "${exitloop}" -eq "0" ] ; then

                if [ ${i} -gt ${timeout} ] ; then

                        echo "/etc/local.d/waitnetwork.start: Cannot reach network after ${i} tries, aborting"

                        exitloop=1

                        success=0

                else

                        sleep 1

                fi

        fi

done

if [ "${success}" -eq "1" ] ; then

        echo "/etc/local.d/waitnetwork.start: network reached after ${i} tries, ok"

        /etc/init.d/ntp-client restart

fi

```

At my place it catches network after 10 s. It works except I log in before network is up, so fluxbox displays wrong date and time during about 1 minute.

----------

## MikeSummers

I have the same problem, adding "sleep 10s" to  /etc/init.d/ntp-client's start() function is a hack fix

----------

## darkphader

I'm a bit loathe to use a workaround and just put the 80-net-name-slot.rules dummy file back in place. Reason is that using the hack only treats the symptom for that one package, and while there may not seem to be other problems right now others may crop up.

It seems to be a serious issue when the startup scripts do not know whether "net" is available or not. This root problem really needs to be resolved here.

----------

## SamuliSuominen

What if instead of using `after net` in /etc/init.d/ntp-client `use net` is used instead?

----------

## SamuliSuominen

 *darkphader wrote:*   

> I'm a bit loathe to use a workaround and just put the 80-net-name-slot.rules dummy file back in place. Reason is that using the hack only treats the symptom for that one package, and while there may not seem to be other problems right now others may crop up.
> 
> It seems to be a serious issue when the startup scripts do not know whether "net" is available or not. This root problem really needs to be resolved here.

 

I agree we need to find the root cause.

I'm suprised to hear adding empty 80-net-name-slot.rules is somehow fixing the problem for you? I can't see anything eth* specific in OpenRC's code that would make difference here

I'll look at dhcpcd next

----------

## darkphader

I see that "after" is also used in the net.* scripts, and maybe others.

Is "after" broken? Would it not be better to just fix "after", or if "after net" is the only broken implementation then maybe it should be fixed or replaced.

----------

## darkphader

[quote="ssuominen"] *darkphader wrote:*   

> I'm suprised to hear adding empty 80-net-name-slot.rules is somehow fixing the problem for you?

 

It's not an empty file it's the dummy file that the udev upgrade installed. Contents are:

```
#

# Udev 197 and above has implemented predictable network interface names

# for hardware network interfaces. This new scheme does not affect

# stacked network interfaces such as bonds, bridges or vlans.

#

# This file is here to prevent your interfaces from being renamed automatically,

# because the new names will be drastically different from the eth*, wlan*, etc

# names you are used to working with.

#

# To activate this function, move this file to a name that doesn't end in.rules,

# or remove it then reboot your system.

#

# If you want to deactivate this function, install a udev rules file as

# /etc/udev/rules.d/80-net-name-slot.rules then reboot your system.

#

# This functionality has not been tested with gentoo. In fact, we are aware that

# things will break if you activate it.

#

# If you are not comfortable testing this, leave this file as is. We will

# publish a news item when you can migrate.

#

# If you do want to activate and help us come up with a migration plan, feel

# free to do so and report bugs.

# Your bugs should block the following tracker:

# https://bugs.gentoo.org/show_bug.cgi?id=450938

#

# Before you activate this function, it is important that you fully understand

# the following documentation:

#

# http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

#

# Also, be aware that you can get the attributes of your network interface that

# would be used to name the interface in the new scheme by doing the following

# with this version of udev running:

#

# udevadm test-builtin net_id /sys/class/net/ifname 2> /dev/null

#

# for example, on my system, I can find that eth0's new name would be enp1s5.

#

```

Notice that it claims (and works that way here) that being in place prevents the new automatic naming system.

----------

## SamuliSuominen

 *darkphader wrote:*   

> It's not an empty file it's the dummy file that the udev upgrade installed.

 

Well, that's what I meant by empty file. 

Are there other files in /etc/udev/rules.d?

----------

## darkphader

 *ssuominen wrote:*   

> Are there other files in /etc/udev/rules.d?

 

I had another file: 10-local.rules containing:

```
#http://kvm.qumranet.com/kvmwiki/Kernel-optimizations

KERNEL=="tun",         NAME="net/%k", GROUP="qemu", MODE="0660"
```

 but I removed it also, as I'm not currently using kvm and I'm not even sure it's still needed if I was. There's sure to be some cruft in my system as the install was probably 6 years ago or more.

----------

## kriegerod

 *darkphader wrote:*   

> I see that "after" is also used in the net.* scripts, and maybe others.
> 
> Is "after" broken? Would it not be better to just fix "after", or if "after net" is the only broken implementation then maybe it should be fixed or replaced.

 

Having subj problem on fresh arm stage3.

Tried adding "use net" statement to /etc/init.d/ntp-client, but didn't help (my active net connection is wireless, and its initscript has that specific of returning before connection is actually functioning.

Currently made a local.d script which loops in background restarting ntp-client each minute. (Correct time is critical for openvpn connection to verify remote party certificate.)

UPD There's a fix described: https://bugs.gentoo.org/show_bug.cgi?id=463974

Just change "after net" to "need net" in init.d script.

----------

