[radvd-devel-l] can't join ipv6-allrouters on (Cannot allocate memory) on 285th interface

Dan White dwhite at olp.net
Wed Apr 1 09:43:44 EDT 2009


Norman Rasmussen wrote:
> setsockopt doesn't return ENOMEM at any point, so it's either, 
> sock_kmalloc in ipv6_sock_mc_join failing or kzalloc in 
> ipv6_dev_mc_inc failing. Either way you're running out of kernel 
> memory, which is very bad.
>
> see: 
> http://www.google.com/codesearch/p?hl=en#CJH4YAGt3ds/net/ipv6/mcast.c&q=linux-2.6.25%20mcast.c%20ipv6_sock_mc_join%20ENOMEM 
> <http://www.google.com/codesearch/p?hl=en#CJH4YAGt3ds/net/ipv6/mcast.c&q=linux-2.6.25%20mcast.c%20ipv6_sock_mc_join%20ENOMEM>
>
> does slabtop show anything interesting?
>
> another thing to check is is errno zero _before_ the setsockopt call? 
> (i.e. is it the setsockopt that's failing, and not just the call 
> immediately before it)
>
> also does it always fails on the same interface? i.e. if you remove 
> the first 10 interfaces, does it:
>    get to 275 interfaces and die - i.e. it's always failing on the 
> same interface
>    get to 285 interfaces and die - i.e. it's successfully configured 
> the 285th interface (but we skipped the first 10)

I modified the patch like this:

--- device-linux.c.bak  2009-04-01 08:20:26.000000000 -0500
+++ device-linux.c      2009-04-01 08:17:56.000000000 -0500
@@ -178,12 +178,14 @@
        mreq.ipv6mr_multiaddr.s6_addr32[0] = 
htonl(0xFF020000);                                         
        mreq.ipv6mr_multiaddr.s6_addr32[3] = htonl(0x2);    
 
+       errno = 0;
        if (setsockopt(sock, SOL_IPV6, IPV6_ADD_MEMBERSHIP, &mreq, 
sizeof(mreq)) < 0)
        {
                /* linux-2.6.12-bk4 returns error with HUP signal but 
keep listening */
                if (errno != EADDRINUSE)
                {
                        flog(LOG_ERR, "can't join ipv6-allrouters on 
%s", iface->Name);
+                       flog(LOG_ERR, "Error %d: %m", errno);
                        return (-1);
                }
        }


And when starting, I get:

Starting radvd: [Apr 01 08:21:40] radvd: can't join ipv6-allrouters on 
bond0.2011.22
[Apr 01 08:21:40] radvd: Error 12: Cannot allocate memory
[Apr 01 08:21:40] radvd: error parsing or activating the config file: 
/etc/radvd.conf
failed.

The error is consistent, in that the 285th interface triggers the error. 
It does not matter which interface I comment out - I've commented out 
the first, the last, several in the middle - as long as I've defined 
284, radvd starts.

I have not used slabtop before, so I'm not sure I would notice something 
out of the ordinary. I've captured the output of /proc/slabinfo just 
before starting radvd, and just after (successfully) starting radvd. You 
can find them here:

http://support.olp.net/radvd/

I also included my complete /etc/radvd.conf, and my debian 
/etc/network/interfaces (which includes IP assignments).

I've tried restarting some other daemons - bind, quagga, dibbler, dhcpd. 
Even with several of them shut down, I'm still hitting the error on the 
284th interface.

I was thinking this could be a resource limit of some sort. I modified 
my start script so that radvd runs as the root user (rather than the 
radvd user), but same thing. This is the output of 'ulimit -a' as the 
root user, just before starting radvd:

north:/etc# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
max nice                        (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) unlimited
max rt priority                 (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

I tried increasing the stack size (ulimit -s 16384) but that didn't help.

I have not tried restarting the system however.

- Dan
//
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.litech.org/pipermail/radvd-devel-l/attachments/20090401/e8c264f5/attachment.htm 


More information about the radvd-devel-l mailing list