Hide Forgot
Description of problem: radvd doesn't start at boot Version-Release number of selected component (if applicable): radvd-1.6-1.el6.x86_64 Steps to Reproduce: 1. enable+configure radvd 2. reboot machine Actual results: radvd not running Expected results: radvd running Additional info: starting radvd manually later on works fine. In /var/log/messages I find this: Jan 10 21:47:42 spunk radvd[1665]: version 1.6 started Jan 10 21:47:42 spunk radvd[1665]: interface eth0 is not RUNNING Jan 10 21:47:42 spunk radvd[1665]: interface eth0 does not exist Jan 10 21:47:42 spunk radvd[1665]: error parsing or activating the config file: /etc/radvd.conf To me this looks like radvd is started before eth0 is up.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
> > To me this looks like radvd is started before eth0 is up. Hi, what about manual starting when system is running. Does it work? If not it could be e. g. hardware issue (test another interface/NIC). Could you provide me dmesg and `ip addr show` outputs. Jiri
Starting manually once the system is up works fine. $ cat /etc/sysconfig/networking/devices/ifcfg-eth0 # hardware DEVICE=eth0 BOOTPROTO=none HWADDR=20:cf:30:e9:be:ff NM_CONTROLLED=no ONBOOT=yes TYPE=Ethernet USERCTL=no # ipv4 IPADDR=192.168.2.14 NETMASK=255.255.255.0 GATEWAY=192.168.2.1 # ipv6 IPV6INIT=yes IPV6ADDR=2001:06f8:1cb3:2::14/64 $ ip addr ls 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 20:cf:30:e9:be:ff brd ff:ff:ff:ff:ff:ff inet 192.168.2.14/24 brd 192.168.2.255 scope global eth0 inet6 2001:6f8:1cb3:2::14/64 scope global valid_lft forever preferred_lft forever inet6 fe80::22cf:30ff:fee9:beff/64 scope link valid_lft forever preferred_lft forever 3: sit0: <NOARP> mtu 1480 qdisc noop state DOWN link/sit 0.0.0.0 brd 0.0.0.0 4: sixxs: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN qlen 500 link/[65534] inet6 2001:6f8:1c00:17e::2/64 scope global valid_lft forever preferred_lft forever inet6 fe80::4f8:1c00:17e:2/64 scope link valid_lft forever preferred_lft forever
Created attachment 474405 [details] dmesg
I'm really not able to reproduced the issue. The dmesg doesn't point to some eth issue. There is only a mass of messages about DVD driver. I've tested possibility to substitute enabling radvd with chkconfig by radvd.conf file in /etc/init (using upstart event). ===================================== respawn console none start on started network ### you use network service stop on [!12345] exec /etc/init.d/radvd start ===================================== Eventually try attach here /var/log/messages.
I havn't seen it happening for a while. It didn't happen on each boot before, so it isn't 100% clear whenever this is just good luck or whenever the issue got fixed. The machine has been upgraded to RHEL 6.1 since I've filed that bug.
(In reply to comment #7) > I havn't seen it happening for a while. It didn't happen on each boot before, > so it isn't 100% clear whenever this is just good luck or whenever the issue > got fixed. The machine has been upgraded to RHEL 6.1 since I've filed that > bug. Thanks for info. Radvd daemon (and not only radvd) is not able to wait till network is up. This is a task for initscripts (you can verify names in /etc/rc[35].d if there is correct order). But I don't suppose this order was source of your troubles. I estimate it on something near to HW troubles e. g. network connection, NIC card, ... I don't think that this bug should currently stay open. Don't hesitate to reopen when the issue will discover again. Then, please, attach /var/log/messages of correct + incorrect booting if possible.