Understanding the timestamp of ltrace

[Franck Youssef]

Hi Pavel,

>> Furthermore, when printing the 'time' object using --time_unit 1s, I obtain some kind of a funny timestamp prefixed with a dash: "-2147483620.50"  (= Fri Dec 13 21:46:19 MET 1901 using date -d @…).
> 
> This seems like a bug. What polygraph version do you use?

I am using the latest public stable release (a.k.a. v. 4.3.2).
Using polygraph-lr, the timing is correct. However, they are false with polygraph-ltrace.

> You could modify sampling interval using '--win_len' option. Do not use '--time_unit' option if you want unix timestamps.
> e.g.
> $ polygraph-ltrace --objects time, err_xact.count --win_len 20sec <lo

Thanks! This works like a charm!

Furthermore, I experience issues when inspecting logs from multiple clients and servers hosts.
When running
$ polygraph-ltrace --object err_xact.count --side all *.log

I obtain the following errors:
server1.log:warning: failed to read log file, skipping
server2.log:warning: failed to read log file, skipping
… for all the servers logs
followed by the "normal" ltrace output based on the clients logs only.

Whey running the same command on the server logs only, the trace is correct and no warnings are issued. It works also correctly with client logs only.
However, when starting to mix client and server logs together, I obtain again warnings on STDERR.

The error happens on any --side all|clt|srv and --sync_times 0|1 combination.
Also possibly related, when using polygraph-reporter on the same logs, the polygraph-reporter app gets killed after passing to server-side plots. The crash does not happen with client logs only.

Is that also a bug, or am I misunderstanding the logging mechanism?


Thank you a lot for your explanations.

Cheers,

Franck