[CRIU] clock_gettime(MONOTONIC) changing after restore

[Cyrill Gorcunov]

On Mon, Aug 03, 2015 at 10:30:37AM -0400, 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.
> 
> 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.

I believe the proper solution is to teach the kernel to accept
time adjustment, I'll talk to kernel camp and report the results, ok?