Summary: | init scripts don't wait for completion of IPv6 address addition | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jan Oravec <jan.oravec> |
Component: | [OLD] baselayout | Assignee: | OpenRC Team <openrc> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | minor | CC: | kernel, radek, uberlord |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Jan Oravec
2007-03-05 12:29:57 UTC
there shouldn't be any delay from the time an address is added to when it's available Are you using parallel startup, and what is youra RC_STRICT_NET_CHECKING value in /etc/conf.d/rc? I am not using parallel startup and RC_NET_STRICT_CHECKING is set to "no". I think that the problem is here: # ip addr add 1234::5678/128 dev eth0; ip addr show dev eth0 | grep 1234; echo "waiting..."; sleep 2; ip addr show dev eth0 | grep 1234 inet6 1234::5678/128 scope global tentative waiting... inet6 1234::5678/128 scope global 'tentative' means, that IPv6 duplicate address detection has not been finished yet and such address cannot be used in bind() call. Also, providing `emerge --info` for completeness: Portage 2.1.2-r9 (default-linux/amd64/2007.0, gcc-4.1.1, glibc-2.5-r0, 2.6.19-gentoo-r5 x86_64) ================================================================= System uname: 2.6.19-gentoo-r5 x86_64 Dual-Core AMD Opteron(tm) Processor 2212 Gentoo Base System release 1.12.9 Timestamp of tree: Mon, 19 Feb 2007 09:20:01 +0000 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=opteron -O3 -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=opteron -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.ynet.sk/pub" LINGUAS="en" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow 3dnowext acl acpi amd64 bash-completion bzip2 caps crypt dbus hal idn ipv6 mmx mmxext ncurses nls nptl pam perl pic python readline sse sse2 ssl udev unicode zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="apm ark ati chips cirrus cyrix dummy fbdev glint i128 i810 mga neomagic nv rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY I can replicate this. FreeBSD and NetBSD have similar behaviour, so I would assume it's not a kernel issue as such. ifconfig does not report tentative at all, so we'll have to hope that users have iproute2 installed. Fixed in my local openrc repo. This is yet another reason why we really should consider pulling in iproute2 to be used over ifconfig in some regards. All, I see that this bug hasn't been touched in a couple of years, so we need to find out if it is still an issue. I'm moving it to test-request so that we can keep track of that. Can someone who has ipv6 please test this bug with openrc-0.6.1 and let us know if this is still an issue? Thanks, William williamh: it works for me, but we need to make sure there is a way to disable it as well, because it can cause problems in some setups (esp. bonded devices). |