In what cases CLOCK_MONOTONIC might not be available

Question

In Java System.nanoTime()'s monotonic implementation on Linux relies on the fact that CLOCK_MONOTONIC is available on the OS. If it's not available, it falls back to gettimeofday which can result in getting a negative time interval when the interval is measured using nanoTime. For instance, the following test might fail.

long t1 = System.nanoTime();
long t2 = System.nanoTime();
assert t2 >= t1

In what cases CLOCK_MONOTONIC might not be available on a server? Is it reasonable to assume that CLOCK_MONOTONIC clock is available on all modern Linux servers?

Walliw

Answer 1

Is it reasonable to assume that CLOCK_MONOTONIC clock is available on all modern Linux servers?

Yes. It is reasonable to assume that.

From the wording of the gettime manual entry, we can infer that really old versions of glibc do not support CLOCK_MONOTONIC. (I am still trying to figure out how old ... but probably when glibc claimed POSIX 1003.1 compliance.)

CLOCK_MONOTONIC was specified (at least) in IEEE Std 1003.1, 2004 Edition, though it remains possible for a compliant libc implementation to not support CLOCK_MONOTONIC.

The Linux kernel source code has had support for a CLOCK_MONOTONIC clock at least since Linux 3.0 (2011).

From other sources, it also depends on how your system's glibc was built. (When built with "emulated timers", CLOCK_MONOTONIC is not supported.)

Here are some cases where it is not supported:

• There can be problems with some old CPU chips; e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1499480

• It is not supported for some (all?) versions of Cygwin.

• It is not supported for some (all?) versions of uCLibc on ARM.

---

It is also possible for CLOCK_MONOTONIC to be supported but buggy:

• Linux clock_gettime(CLOCK_MONOTONIC) strange non-monotonic behavior

Meingolda

For what it's worth, I just ran into an issue where my JVM was complaning no monotonic clock was available. I'm running a docker container with the adoptopenjdk:15.0.1_9-jre-hotspot for armv7 as base image. The host system is a raspberry pi model 4 running the latest raspberry pi os (kernel 5.4). Not sure if related, but after the warning it seems to freeze/hang. – Matthaus

Fixed it by reverting to adoptopenjdk/openjdk14:armv7l-debianslim-jre-14.0.2_12 base image... currently, it seems hard to find a good working openjdk jre 15 for 32bit armv7... – Matthaus

@PimHazebroek man, you just saved me hours of looking why this monotonic clock was not available on RPI 2 Docker for ARM v7 (and in result preventing from properly running Spring Boot application)... Picking up this openjdk14 stopped from raising the issue. Nevertheless - waiting for some proper OpenJDK 15 image. Is it really so niche to run Java on ARM v7? – Epigram

Answer 2

Is it reasonable to assume that CLOCK_MONOTONIC clock is available on all modern Linux servers?

I can only comment on this question. Yes, it's reasonable that all production-grade systems you use will have a monotonic clock that Linux knows how to access. This is also true of virtual and container servers.

Good engineering dictates you put a check in for this and error-out if an assumption is broken, but I would count on this at design-time.

Charinile