[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: [BusyBox] udhcpc renew on signal bug - Busybox 1.0 CVS
From:       Joshua Jackson <busybox () vortech ! net>
Date:       2003-10-25 18:06:16
[Download RAW message or body]

On Thursday 23 October 2003 9:17 pm, Russ Dill wrote:
>
> udhcp uses an fdset because its the only safe way of waiting on select
> and expecting to reliably get signals.

I see.

> > 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.
>
> [...]
>
> 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.

No, the machines doing this are time sync'd to a NTP server everytime they 
boot, which is written to the hardware clock after a successful sync. I can 
duplicate this on production hardware and in vmware test machines. I looked 
into wether or not the clock was drifting, thinking that maybe each time it 
booted the dhcp client was started prior to the time sync, causing a large 
difference in start time vs. current system time... but that is not 
happening.

In addition, I have managed to duplicate the problem by starting the client 
and killing it right back off from a command line. It does not occur every 
time the client is sent a signal, but it does happen frequently enough that I 
can reliably reproduce the problem.

--
Joshua Jackson
Vortech Consulting, LLC
http://www.vortech.net

_______________________________________________
busybox mailing list
busybox@mail.busybox.net
http://codepoet.org/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]