FW: udhcpd listening on all interfaces

Denys Vlasenko vda.linux at googlemail.com
Tue May 3 01:19:36 UTC 2011


On Tuesday 26 April 2011 21:34, Blanchette, Sylvie wrote:
> Resending in plain text...
> ________________________________________
> From: Blanchette, Sylvie 
> Sent: Wednesday, April 20, 2011 2:40 PM
> To: busybox at busybox.net
> Subject: udhcpd listening on all interfaces
> 
> Hi,
> 
> Even though I have setup the interface parameter in udhcpd.conf to eth0, udhcpd still responds to bootp requests coming in on other interfaces on the node and spawns udhcpd processes using up sockets and memory. The list of udhcpd processes and number of sockets used on the system keeps growing over time leading to a kernel panic because we run out of memory.

As far as I know, udhcpd does not spawn children fro every client.

It uses a child process only if notify_file directive is present
in config file.

I don't understand how did you manage to have so many children
udhcpd processes. I need more data.

> Node1:~$ netstat -a
> Active Internet connections (servers and established)
> Proto Recv-Q Send-Q Local Address           Foreign Address         State       
> tcp        0      0 0.0.0.0:telnet          0.0.0.0:*               LISTEN      
> tcp        0      0 :::26                   ::%2143958320:*         LISTEN      
> udp        0      0 0.0.0.0:bootps          0.0.0.0:*                           
> udp        0      0 0.0.0.0:bootps          0.0.0.0:*                           
> udp        0      0 0.0.0.0:bootps          0.0.0.0:*                           
> udp     1856      0 10.1.5.18:bootps        onw-tpaskara-01.ciena.com:bootpc ESTABLISHED 
> udp        0      0 0.0.0.0:bootps          0.0.0.0:*                           
> udp        0      0 0.0.0.0:bootps          0.0.0.0:*                           
> udp     1856      0 10.1.5.18:bootps        onw-tpaskara-01.ciena.com:bootpc ESTABLISHED 
> udp     1856      0 localhost:bootps        localhost:bootpc        ESTABLISHED 
> udp        0      0 0.0.0.0:bootps          0.0.0.0:*                           
> udp     1856      0 localhost:bootps        localhost:bootpc        ESTABLISHED 
> udp        0      0 0.0.0.0:bootps          0.0.0.0:*                           
> udp     1856      0 localhost:bootps        localhost:bootpc        ESTABLISHED 
> udp        0      0 0.0.0.0:bootps          0.0.0.0:*                           
> udp     1856      0 10.1.5.18:bootps        onw-jmagnet-01.ciena.com:bootpc ESTABLISHED 
> udp        0      0 0.0.0.0:bootps          0.0.0.0:*                           
> udp     1856      0 localhost:bootps        localhost:bootpc        ESTABLISHED 
> udp        0      0 0.0.0.0:bootps          0.0.0.0:*                           
> udp     1856      0 localhost:bootps        localhost:bootpc        ESTABLISHED 
> udp        0      0 0.0.0.0:bootps          0.0.0.0:*                           
> udp     1856      0 localhost:bootps        localhost:bootpc        ESTABLISHED 
> udp        0      0 0.0.0.0:bootps          0.0.0.0:*                           
> udp     1856      0 10.1.5.18:bootps        10.1.29.89:bootpc       ESTABLISHED 
> udp        0      0 0.0.0.0:bootps          0.0.0.0:*                           
> udp     1856      0 10.1.5.18:bootps        10.1.28.81:bootpc       ESTABLISHED 
> udp        0      0 0.0.0.0:bootps          0.0.0.0:*                           
> udp     1856      0 10.1.5.18:bootps        10.1.5.2:bootpc         ESTABLISHED 
> udp        0      0 0.0.0.0:bootps          0.0.0.0:*                           
> udp     1856      0 10.1.5.18:bootps        10.1.5.13:bootpc        ESTABLISHED 
> udp        0      0 0.0.0.0:bootps          0.0.0.0:*                           
> udp     1856      0 10.1.5.18:bootps        10.1.5.13:bootpc        ESTABLISHED 
> udp        0      0 0.0.0.0:bootps          0.0.0.0:*                           
> udp     1856      0 10.1.5.18:bootps        10.1.5.36:bootpc        ESTABLISHED 
> udp        0      0 0.0.0.0:tftp            0.0.0.0:*                           
> udp        0      0 0.0.0.0:snmp            0.0.0.0:*                           
> udp        0      0 :::6161                 ::%2144671120:*                     
> Active UNIX domain sockets (servers and established)
> Proto RefCnt Flags       Type       State         I-Node Path
> ...
> 
> Node1:~$ ps -ef | grep udhcpd
> root      3332     1  0 13:26 ?        00:00:00 udhcpd
> root      3336     1  0 13:27 ?        00:00:00 udhcpd
> root      3347     1  0 13:29 ?        00:00:00 udhcpd
> root      3349     1  0 13:29 ?        00:00:00 udhcpd
> root      3366     1  0 13:41 ?        00:00:00 udhcpd
> root      3370     1  0 13:42 ?        00:00:00 udhcpd
> root      3374     1  0 13:42 ?        00:00:00 udhcpd
> root      3382     1  0 13:49 ?        00:00:00 udhcpd
> root      3384     1  0 13:49 ?        00:00:00 udhcpd
> root      3386     1  0 13:49 ?        00:00:00 udhcpd
> root      3388     1  0 13:49 ?        00:00:00 udhcpd
> root      3397     1  0 13:56 ?        00:00:00 udhcpd
> root      3400     1  0 13:56 ?        00:00:00 udhcpd
> root      3401     1  0 13:56 ?        00:00:00 udhcpd
> root      3403     1  0 13:56 ?        00:00:00 udhcpd
> root      3407     1  0 13:58 ?        00:00:00 udhcpd
> root      3416     1  0 14:03 ?        00:00:00 udhcpd
> root      3419     1  0 14:04 ?        00:00:00 udhcpd
> gss       3421  3338  0 14:04 ttyS0    00:00:00 grep udhcpd
> 
> I want to use only the bootp feature of udhcpd on this particular node type in order to boot an intelligent module on that node. The node is not to be used as a DHCP server. The IP address of the port connecting the main board to the intelligent module is fixed.

What do you mean by "want to use only the bootp feature"?

Can you show your .config and udhcpd.conf?

Can you "killall udhcpd", run "strace -f -s99 -tt -oLOG udhcpd -f <other opts>",
reproduce the bug (appearance of a few children) and post LOG file?

Can you reproduce this bug with latest released version - 1.18.4?


> I am in the process of bringing in the latest version of busybox into our image, but it would be nice to know if someone else has observed this issue before and if there is a temporary solution that I can use to work around it.

-- 
vda


More information about the busybox mailing list