[BusyBox] udhcpc renew on signal bug - Busybox 1.0 CVS

[Russ Dill]

On Thu, 2003-10-23 at 18:01, Joshua Jackson wrote:
> I sent a message to the list a little while back about a DHCP client renew 
> "storm" and am pretty sure I have figured out what is going on, but am a 
> little stumped by the way udhcpc handles signals...
> 
> In the event that udhcpc receives a SIGTERM, it will frequently lauch a dozen 
> or so renew requests onto the network. During a system reboot, init will kill 
> off syslogd prior the udhcpc client (at least the way my systems are 
> configured) and it looks pretty goofy seeing a dozen or better renew requests 
> being sent during the system shutdown.

surely there is a problem

> The best I can figure without spending a whole lot of time trying to figure 
> out why udhcpc uses an FDSET to listen for signals is that the fact that the 
> state machine is in a "BOUND" state when the signal is initially received - 
> as the same state loop is used for signal processing and normal operation, 
> sending a SIGTERM triggers "case BOUND:" as it runs through the pile of 
> if/case statements and triggers the following code block:

udhcp uses an fdset because its the only safe way of waiting on select
and expecting to reliably get signals.

> As the presence of an actual signal is not checked until last, a bunch
> of code that should not be run gets launched.

no, it'll only go through that if select returns 0, ie, times out.

if (tv.tv_sec > 0) {
	DEBUG(LOG_INFO, "Waiting on select...\n");
        max_fd = signal_pipe[0] > fd ? signal_pipe[0] : fd;
        retval = select(max_fd + 1, &rfds, NULL, NULL, &tv);
} else retval = 0; /* If we already timed out, fall through */
                                                                                now = time(0);
if (retval == 0) {
        /* timeout dropped to zero */

select man page:

On success, select and pselect return the number  of  descriptors  con-
tained in the descriptor sets, which may be zero if the timeout expires
before anything interesting happens.  On error,  -1  is  returned,  and
errno  is  set appropriately; the sets and timeout become undefined, so
do not rely on their contents after an error.

[...]

EINTR  A non blocked signal was caught.


> Just my $.02, and I may be way off base here... I only spent about 10 minutes 
> looking at the code. Most of the busybox code has been very easy for me to 
> work with... In this case, the difference in coding style from my own makes 
> my brain hurt :P

looks like the same coding style as the rest of busybox to me...

> However, the dozen or so extraneous requests is definately not proper 
> behaviour for a DHCP client.

right, are you sure you aren't doing something that is making udhcp
timeout? like set the date to some random value? are you sure udhcp is
actually acting on a sigterm before doing these renews? I don't get that
behaviour when I kill udhcp, maybe you should put some debug statements
in.

> --
-- 
Russ Dill <Russ.Dill at asu.edu>