content-type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Content-Length: 2281

Thanks again for quick reply, but the crucial point is here

>select takes a relative time so if you are lucky it is recomputed
with the "new" current time.

This recomputation goes wrong.
As can be seen from 'strace `pidof dhclient`' output, select() sleeps for
the difference between current time and next scheduled time!

It can be easily reproduced  by setting "lease time" on server to 60
seconds and shift time on client to some point in past.

More detailed reproduction:
0. dhclient receives settings
1. sleeps in select() for the lease time/2; -  strace `pidof dhclient`
shows some decent 15-30 seconds
2.  system time shifts back on some hour
3. dhclient wakes up, discovers that shift ant goes to sleep on that time
shift! So if you are switching back to 80 days it will sleep on 80 days.
Again can be easily checked by usage of `strace`.


2017-07-11 16:34 GMT+03:00 Francis Dupont via RT <dhcp-confidential@isc.org>
:

> On Tue Jul 11 09:30:12 2017, kunschikov@gmail.com wrote:
> >       We are using CentOS as base system and can't switch to BSD.
>
> => I said BSDs because it was invented for 4.3 BSD in 1993
> (and I used this system at that time). Note adjtime() is supported
> by Linux too (cd http://man7.org/linux/man-pages/man3/adjtime.3.html)
>
> > I am not
> > sure which signal can be sent to the dhclient in order to recalculate
> > sleep/wake timestamps. Select can be canceled on signal reception but
> after
> > that dhclient is going to sleep again till the next date, which is
> > calculated not from current time, but from the scheduled one.
>
> => you can send a signal to the process (but avoid to kill it).
> select takes a relative time so if you are lucky it is recomputed
> with the "new" current time.
>
> > I am solving this problem by replacing gettimeofday() with
> > clock_gettime(CLOCK_MONOTONIC_RAW,..) for dhclient. LD_PRELOAD with
> > gettimofday()# replacement library does the trick.  #Proper solution will
> > require modification of the dhclient scheduler.
>
> => you solution deals with the problem at its root (not increasing
> gettimeofday). I am not sure it is correct to modify the scheduler:
> the assumption the current time is increasing is not so crazy...
>
> > Thanks for quick reply.
>
> => can we close the ticket?
>
>