SYSUPTIME value description could be inaccurate

[HofiOne]

Version of syslog-ng

syslog-ng 3 (3.24.1)

Platform

Yocto - Linux embedded (ARM64).

Question

The on-line documentation states for ${SYSUPTIME}:

The time elapsed since the syslog-ng OSE instance was started (that is, the uptime of the syslog-ng OSE process). The value of this macro is an integer containing the time in 1/100th of the second.

This is only true if the device's clock is already close to the actual time and does not “jump” back or forth during runtime.

I make use of ${SYSUPTIME} in the template of some destination on devices where the clock always starts from 'epoch' at boot time and then jumps forward due to NTP.

This is an example of the logs I get:

1970-01-01T00:00:30+01:00 2446 debug core: Resetting PHY of eth2
1970-01-01T00:00:30+01:00 2446 debug core: Resetting PHY of eth1
1970-01-01T00:00:30+01:00 2447 debug core: Resetting PHY of eth0
1970-01-01T01:00:31+01:00 2565 debug dev: SNMP Agent snmpd -- pid change 608 --> 667
2025-07-14T15:02:30+02:00 175249814481 notice dev: Emitting trap: coldStart
2025-07-14T15:02:32+02:00 175249814715 info auth: Login success [user: root][source: 192.168.5.1][service: ssh]

Since it is tied to the system clock, for all entries logged after clock synchronisation ${SYSUPTIME} no longer represent ‘The time elapsed since the syslog-ng OSE instance was started’.

In my case I put ${SYSUPTIME} in the template precisely in the hope of having a time reference for those entries logged before the clock synchronisation.

Proposal

Update the on-line documentation with a more accurate description of ${SYSUPTIME} so that the value is consistent with what is described.

NOTE: This is moved from syslog-ng/syslog-ng#5415

[flinco]

I would like to emphasise that I opened syslog-ng/syslog-ng#5415 using the conditional (“could be”) in the title because I personally think that the most correct solution is to leave the documentation as it is and patch the code so that the value returned is as stated.

This would make it more useful (IMHO) and consistent with similar values used and returned, for example, in SNMP (see OID .1.3.6.1.2.1.1.3.0 sysUpTime).

[HofiOne]

Understood, but I would not change the original behavior, even if it isn’t ideal, as I’d prefer to avoid breaking backward compatibility (even if the current implementation isn’t necessarily the best). Instead, I’d rather add a new macro, like ${APPUPTIME}, and implement the improved behavior there.

Please create a new feature request for that if you’d like to have it. You don’t need to explain everything again — just link to one of these discussions in the description of the request.

Thank you.