Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
udev-200, ntp-client fails before network is up
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
ecko
n00b
n00b


Joined: 04 Jul 2010
Posts: 61

PostPosted: Sat Mar 30, 2013 4:33 pm    Post subject: udev-200, ntp-client fails before network is up Reply with quote

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.
Back to top
View user's profile Send private message
darkphader
Veteran
Veteran


Joined: 09 May 2002
Posts: 1131
Location: Motown

PostPosted: Sat Mar 30, 2013 5:49 pm    Post subject: Reply with quote

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.
_________________
What I need is an exact list of specific unknown problems we might encounter.
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2128
Location: Finland

PostPosted: Sat Mar 30, 2013 5:57 pm    Post subject: Reply with quote

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.
# A hotplugged service is one started by a dynamic dev manager when a matching
# hardware device is found.
# This service is intrinsically included in the boot runlevel.
# To disable services, prefix with a !
# Example - rc_hotplug="net.wlan !net.*"
# This allows net.wlan and any service not matching net.* to be plugged.
# Example - rc_hotplug="*"
# This allows all services to be hotplugged
#rc_hotplug="*"


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.
Back to top
View user's profile Send private message
ecko
n00b
n00b


Joined: 04 Jul 2010
Posts: 61

PostPosted: Sat Mar 30, 2013 8:23 pm    Post subject: Reply with quote

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
Code:
#!/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.
Back to top
View user's profile Send private message
MikeSummers
n00b
n00b


Joined: 31 May 2003
Posts: 38
Location: Kansas City

PostPosted: Sun Mar 31, 2013 2:36 pm    Post subject: Reply with quote

I have the same problem, adding "sleep 10s" to /etc/init.d/ntp-client's start() function is a hack fix
Back to top
View user's profile Send private message
darkphader
Veteran
Veteran


Joined: 09 May 2002
Posts: 1131
Location: Motown

PostPosted: Sun Mar 31, 2013 3:05 pm    Post subject: Reply with quote

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.
_________________
What I need is an exact list of specific unknown problems we might encounter.
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2128
Location: Finland

PostPosted: Sun Mar 31, 2013 3:33 pm    Post subject: Reply with quote

What if instead of using `after net` in /etc/init.d/ntp-client `use net` is used instead?
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2128
Location: Finland

PostPosted: Sun Mar 31, 2013 3:35 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
darkphader
Veteran
Veteran


Joined: 09 May 2002
Posts: 1131
Location: Motown

PostPosted: Sun Mar 31, 2013 3:39 pm    Post subject: Reply with quote

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.
_________________
What I need is an exact list of specific unknown problems we might encounter.
Back to top
View user's profile Send private message
darkphader
Veteran
Veteran


Joined: 09 May 2002
Posts: 1131
Location: Motown

PostPosted: Sun Mar 31, 2013 3:43 pm    Post subject: Reply with quote

[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:
Code:
#
# 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.
_________________
What I need is an exact list of specific unknown problems we might encounter.
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2128
Location: Finland

PostPosted: Sun Mar 31, 2013 3:50 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
darkphader
Veteran
Veteran


Joined: 09 May 2002
Posts: 1131
Location: Motown

PostPosted: Sun Mar 31, 2013 4:47 pm    Post subject: Reply with quote

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


I had another file: 10-local.rules containing:
Code:
#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.
_________________
What I need is an exact list of specific unknown problems we might encounter.
Back to top
View user's profile Send private message
kriegerod
n00b
n00b


Joined: 08 Oct 2013
Posts: 7

PostPosted: Mon Nov 04, 2013 9:47 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum