mjhjmtu

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"?

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.

Verification:

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.

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_MONOTONIC

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
ActiveEnterTimestampMonotonic=14341647533587

and

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

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