[CRIU] clock_gettime(MONOTONIC) changing after restore

[Pavel Emelyanov]

On 08/03/2015 05:30 PM, Christopher Covington wrote:
> Hi Cyrill,
> 
> On 08/03/2015 08:53 AM, Cyrill Gorcunov wrote:
>> On Mon, Aug 03, 2015 at 08:31:31AM -0400, Christopher Covington wrote:
>>> Hi,
>>>
>>> We have notice clock_gettime(MONOTONIC) calls changing significantly across
>>> checkpoint and restore using CRIU circa 1.3-rc2. We'll be moving to the latest
>>> tip soon, but I was wondering if anyone knew off the top of their head whether
>>> we should expect different behavior from a newer CRIU, or if
>>> clock_gettime(MONOTONIC) (maybe CLOCK_MONOTONIC* and CLOCK_BOOTTIME?) should
>>> be listed on the following wiki page:
>>>
>>> http://criu.org/What_can_change_after_C/R
>>
>> Could you provide mode detals please (which values are not adjusted?).
>> Currently we try to adjust timer's values if they were set to absolute
>> time (pie/restorer.c:613). This concerns timerfd only. If the problem
>> in result of clock_gettime syscall itself -- then we indeed do not
>> intercept this calls neither adjust their results.
> 
> We're looking at a Java application that calls System.nanoTime().
> 
> http://stas-blogspot.blogspot.com/2012/02/what-is-behind-systemnanotime.html
> 
> Perhaps the folks on this list can think of better ways to handle this, but
> the following come to mind:
> 
> A) LD_PRELOAD a wrapper that fixes up the clock_gettime system call. This
> works for the issue we're seeing, but it wouldn't handle statically compiled
> executables or hand-coded clock_gettime system calls.
> 
> B) Change the kernel to allow setting the monotonic clock. The whole point of
> the monotonic clock is that it can't be modified at run time, but maybe a boot
> parameter would be acceptable? One would have to estimate and add in the time
> it takes for the system to boot/kexec and run CRIU restore.

This is the way we ... expect it to be fixed. The effort is known by the title
"time namespace", when a new container starts we may be able to specify some
time offset that will be applied to all the time-ings we will get from the kernel.

-- Pavel

> C) Fix up the gettime system call using ptrace syscall, presumably adversely
> affecting performance.
> 
> D) If the gettime system call goes through the VDSO, ptrace poke some code to
> fix it up there.
> 
> Thanks,
> Christopher Covington
>