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