View previous topic :: View next topic |
Author |
Message |
ecko Tux's lil' helper
Joined: 04 Jul 2010 Posts: 99
|
Posted: Sat Mar 30, 2013 4:33 pm Post subject: udev-200, ntp-client fails before network is up |
|
|
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 |
|
|
darkphader Veteran
Joined: 09 May 2002 Posts: 1217 Location: Motown
|
Posted: Sat Mar 30, 2013 5:49 pm Post subject: |
|
|
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. _________________ WYSIWYG - What You See Is What You Grep |
|
Back to top |
|
|
SamuliSuominen Retired Dev
Joined: 30 Sep 2005 Posts: 2133 Location: Finland
|
Posted: Sat Mar 30, 2013 5:57 pm Post subject: |
|
|
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 |
|
|
ecko Tux's lil' helper
Joined: 04 Jul 2010 Posts: 99
|
Posted: Sat Mar 30, 2013 8:23 pm Post subject: |
|
|
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 |
|
|
MikeSummers n00b
Joined: 31 May 2003 Posts: 38 Location: Kansas City
|
Posted: Sun Mar 31, 2013 2:36 pm Post subject: |
|
|
I have the same problem, adding "sleep 10s" to /etc/init.d/ntp-client's start() function is a hack fix |
|
Back to top |
|
|
darkphader Veteran
Joined: 09 May 2002 Posts: 1217 Location: Motown
|
Posted: Sun Mar 31, 2013 3:05 pm Post subject: |
|
|
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. _________________ WYSIWYG - What You See Is What You Grep |
|
Back to top |
|
|
SamuliSuominen Retired Dev
Joined: 30 Sep 2005 Posts: 2133 Location: Finland
|
Posted: Sun Mar 31, 2013 3:33 pm Post subject: |
|
|
What if instead of using `after net` in /etc/init.d/ntp-client `use net` is used instead? |
|
Back to top |
|
|
SamuliSuominen Retired Dev
Joined: 30 Sep 2005 Posts: 2133 Location: Finland
|
Posted: Sun Mar 31, 2013 3:35 pm Post subject: |
|
|
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 |
|
|
darkphader Veteran
Joined: 09 May 2002 Posts: 1217 Location: Motown
|
Posted: Sun Mar 31, 2013 3:39 pm Post subject: |
|
|
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. _________________ WYSIWYG - What You See Is What You Grep |
|
Back to top |
|
|
darkphader Veteran
Joined: 09 May 2002 Posts: 1217 Location: Motown
|
Posted: Sun Mar 31, 2013 3:43 pm Post subject: |
|
|
[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. _________________ WYSIWYG - What You See Is What You Grep |
|
Back to top |
|
|
SamuliSuominen Retired Dev
Joined: 30 Sep 2005 Posts: 2133 Location: Finland
|
Posted: Sun Mar 31, 2013 3:50 pm Post subject: |
|
|
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 |
|
|
darkphader Veteran
Joined: 09 May 2002 Posts: 1217 Location: Motown
|
Posted: Sun Mar 31, 2013 4:47 pm Post subject: |
|
|
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. _________________ WYSIWYG - What You See Is What You Grep |
|
Back to top |
|
|
kriegerod n00b
Joined: 08 Oct 2013 Posts: 7
|
Posted: Mon Nov 04, 2013 9:47 am Post subject: |
|
|
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 |
|
|
|