When I execute the following

systemctl show --all tomcat

I get a bunch of properties including ones like "ActiveEnterTimestampMonotonic". This property has a value of a very large number like "14786979371795". This appears to be too large to be the number of milliseconds since the epoch since the service entered an active state. This also seems to small to be nanoseconds since the epoch that the service entered an active state. So what is it? What is a "TimestampMonotonic"?

  • Is your machine uptime approx. 4 hours or approx. 171 days?
    – schily
    Jul 3, 2018 at 16:18
  • 172 days and some change. Jul 3, 2018 at 18:01

2 Answers 2


A description on the D-Bus ABI of systemd on freedesktop.org describes the timestamps as follows:

InactiveExitTimestamp, InactiveExitTimestampMonotonic, ActiveEnterTimestamp, ActiveEnterTimestampMonotonic, ActiveExitTimestamp, ActiveExitTimestampMonotonic, InactiveEnterTimestamp, InactiveEnterTimestampMonotonic contain CLOCK_REALTIME and CLOCK_MONOTONIC 64bit usec timestamps of the last time a unit left the inactive state, entered the active state, exited the active state, or entered an inactive state. These are the points in time where the unit transitioned inactive/failed → activating, activating → active, active → deactivating, and finally deactivating → inactive/failed. The fields are 0 in case such a transition has not been recording on this boot yet.

It's a bit hidden, but it says "usec timestamps" in the middle, i.e. microseconds (μs).

systemd obtains its timestamps from Linux, which provides a system API function named clock_gettime() for obtaining the time from one of several alternative "clocks". As its documentation says there, it asks for the so-called CLOCK_REALTIME and CLOCK_MONOTONIC ones.

The manual for that function says (emphasis mine):

Clock that cannot be set and represents monotonic time since some unspecified starting point. This clock is not affected by discontinuous jumps in the system time (e.g., if the system administrator manually changes the clock), but is affected by the incremental adjustments performed by adjtime(3) and NTP.

On my system, the values appear to correspond to the starting point being the system boot time, but we probably shouldn't rely on that. (Note what the Linux manual also says about the difference between CLOCK_BOOTTIME and CLOCK_MONOTONIC.)

The *TimestampMonotonic values could be used for calculating intervals, or you could use the realtime timestamps if you want the dates and times. If you have timer units, note that their relative time settings work in terms of monotonic time.

As an empirical experiment, I restarted a particular service a moment ago and just now to refresh the timestamps. The values I got were:

ActiveEnterTimestamp=Tue 2018-07-03 18:37:31 EEST


ActiveEnterTimestamp=Tue 2018-07-03 19:03:04 EEST

The difference is 14343180833503 - 14341647533587, or 1533299916, which is about those intervening 25.5 minutes in microseconds.

  • Since the POSIX standard says, that clock_gettime() return seconds and nanoseconds, you seem to be mistaken.
    – schily
    Jul 3, 2018 at 15:54
  • 1
    @schily, The resolution of the system call isn't necessarily the same as the resolution systemd uses to present the values. Like I said, the numbers I get appear to match microseconds.
    – ilkkachu
    Jul 3, 2018 at 16:00
  • 1
    ilkkachu is correct.
    – JdeBP
    Jul 3, 2018 at 16:06
  • If he was correct, then the machine from the questioner needs to have an uptime of 171 days.
    – schily
    Jul 3, 2018 at 16:17
  • 3
    @schily, I don't know what the systemd developers have thought: you'll have to ask them.
    – ilkkachu
    Jul 3, 2018 at 16:31

Solaris has a gethrtime() function since 28 years and that returns monotonic nanoseconds since boot.

Your number would match 4 hours of uptime and since the author of systemd did look at Solaris, there is enough probability that this is nanoseconds since boot.


14786979371795 divided by a billion results in 14786.979371795 seconds

14786.979371795 seconds divided by 60 seconds result in 246.4496561965 minutes

246.4496561965 minutes are 4.1074942699 hours

Since the feedback resultet in an uptime of 172 days, it is obvious that the number is microseconds since last boot in case the number is based on the monotonic clock from clock_gettime()

BTW: a monotonic counter that counts nanoseconds would allow an uptime of up to 1696 years with a signed 64 bit number.

  • 1
    Thank you for your quick answer! My up time is 172 days and some change. So I think that this isn't quite correct. However, it was the concept I was after. Basically monotonic time is the amount of time since the machine was last booted. So in my case, my service was started 172 days after the machine was first booted. Jul 3, 2018 at 18:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .