We are using CentOS as base system and can't switch to BSD. 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.
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.
Thanks for quick reply.

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

> On Tue Jul 11 08:59:50 2017, kunschikov@gmail.com wrote:
> > Hello,
> >   we have met the following network setup problem.
> > A shift of the system time to the past leads to the incorrect long sleep
> of
> > the dhclient.
> > Step by step reproduction:
> >
> > 1. obtain address via dhclient at timestamp t1;
> > 2. shift system time  to the past to timestamp t2;
> > 3.  bug: dhclient misses renew operation. it is sleeping in 'select' for
> > "lease time"/2 + (t1 - t2) seconds.
> >
> > Time shift can be great, for example in setting up local time on guest
> > linux OSes in some hypervisors.  It consequently leads to the losing
> > address of the interface.
>
> => if you use ISC DHCP 4.1 you can try 4.3 which has a different
> timer library. You can also try to send a signal to the server in
> order to make it to break and restart the select loop.
> Note I don't know for Lines but BSDs provide an option to shift
> system time without stepping it. Of course it does not work
> for big shifts.
> To finish I am not surprise a protocol relying on timing has some
> problems with a not increasing clock...
>
>