Em relação aos serviços do systemd, o que o timestamp monotonic significa?

Question

Quando executo o seguinte

systemctl show --all tomcat

Eu recebo várias propriedades, incluindo "ActiveEnterTimestampMonotonic". Esta propriedade tem um valor de um número muito grande como "14786979371795". Isso parece ser muito grande para ser o número de milissegundos desde a época, já que o serviço entrou em um estado ativo. Isso também parece pequeno para ser nanossegundos desde a época em que o serviço entrou em um estado ativo. Então o que é? O que é um "TimestampMonotonic"?

    

Answer 1

O Solaris tem uma função gethrtime() desde 28 anos e retorna nanossegundos monotônicos desde a inicialização.

Seu número corresponderia a 4 horas de tempo de atividade e, como o autor do systemd consultou o Solaris, há probabilidade suficiente de que isso seja nanossegundo desde a inicialização.

Verificação:

14786979371795 dividido por um resultado bilhões em 14786.979371795 segundos

14786.979371795 segundos divididos por 60 segundos resultam em 246.4496561965 minutos

246.4496561965 minutos são 4.1074942699 horas

Como o feedback resulta em um tempo de atividade de 172 dias, é óbvio que o número é de microssegundos desde a última inicialização, caso o número seja baseado no relógio monotônico de clock_gettime()

BTW: um contador monótono que conta nanossegundos permitiria um uptime de até 1696 anos com um número de 64 bits assinado.

    

Answer 2

Uma descrição na ABI do D-Bus do systemd no freedesktop.org descreve os timestamps como segue:

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.

É um pouco oculto, mas diz "usec timestamps" no meio, ou seja, microssegundos (μs).

O systemd obtém seus timestamps do Linux, que fornece uma função API do sistema chamada clock_gettime() para obter o tempo de um dos vários "clocks" alternativos. Como a documentação diz lá, ele pede os chamados CLOCK_REALTIME e CLOCK_MONOTONIC .

O manual para essa função diz _{(ênfase minha) sub>:}

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.

No meu sistema, os valores parecem corresponder ao ponto de partida sendo o tempo de inicialização do sistema, mas provavelmente não devemos confiar nisso. (Observe o que o manual do Linux também diz sobre a diferença entre CLOCK_BOOTTIME e CLOCK_MONOTONIC .)

Os valores *TimestampMonotonic podem ser usados para calcular intervalos ou você pode usar os registros de data e hora em tempo real se desejar as datas e horas. Se você tiver unidades de temporizador, observe que as configurações de tempo relativas delas funcionam em termos de tempo monótono.

Como experimento empírico, reiniciei um determinado serviço há pouco e agora para atualizar os timestamps. Os valores que recebi foram:

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

e

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

A diferença é 14343180833503 - 14341647533587 , ou 1533299916 , que é sobre aqueles que intervêm 25,5 minutos em microssegundos.