Define a macro alternative to ${SYSUPTIME} holding the actual uptime

[flinco]

Description of the problem

The macro ${SYSUPTIME} represent the

The time elapsed since the syslog-ng OSE instance was started

but it is sensitive to clock changes (i.e. due to NTP).

In fact, the value of ${SYSUPTIME} is calculated as the difference between the current clock and the clock stored at application startup, and if the clock jumps forward, it becomes inconsistent (at least with respect to its definition by the documentation).

Proposed solution

In order not to break backwards compatibility, it is proposed to define and make available a new macro that actually contains the number of hundredths of a second from boot or application start-up. Some proposals:

• ${REALUPTIME};
• ${BOOTUPTIME} (could take into account the uptime from boot to application startup, and add it as an offset each time the macro is used)
• ${APPUPTIME} (proposed in syslog-ng/syslog-ng#213 but, IMHO, misleading in meaning because it should really be swapped with ${SYSUPTIME}).

[HofiOne]

Thank you!

[flinco]

I developed and tested this patch on code 3.24.1 and it proved to work.

It defines a macro called ${BOOTUPTIME} whose value is the number of seconds elapsed since boot. The code reads the value from a struct sysinfo filled by sysinfo(...) (exactly as BusyBox does internally when called as uptime). The only flaw is that the value returned is in seconds instead of hundredths of a second.

P.S.: Please rename the patch from .txt to .patch or .diff (I had to rename it, otherwise the upload fails).

[fkdyufu]

Hello, I'm also looking to add a boot uptime to my log messages. Is it possible to increase its precision to the millisecond level?

[flinco]

Hello, I'm also looking to add a boot uptime to my log messages. Is it possible to increase its precision to the millisecond level?

With a patch similar to mine, but which opens and reads /proc/uptime instead of calling sysinfo(), you can get to the hundredth of a second. This, however, is computationally heavier than sysinfo() because there are more system calls and context changes, and it goes through the proc virtual filesystem.

I have no idea if there are ways to get the thousandths of a second.