Understanding the timestamp of ltrace

[Pavel Kazlenka]

Hi,

On 07/18/2013 01:29 AM, Dmitry Kurochkin wrote:
> Hi Frank, Pavel.
>
> Pavel Kazlenka <panya_qwert at tut.by> writes:
>
>> Hi Franck,
>>
>> Sorry for obvious action, but could you check unix file
>> permissions/owners for log files? If you e.g. scp'ed server logs to
>> client machine there is a chance that user running polygraph-ltrace
>> really have no permission to read *.log file.
>>
> It does not seem like a permission problem since the same command works
> for server side only logs.

Agree. I performed several tests. Seems like polygraph-ltrace is unable 
to process server and client logs at the same run. Modern polygraph 
versions print something like this:

polygraph/bin/polygraph-ltrace --side all --objects time,ok_xact.count  
last/*.log
warning: log(s) have info from client and server sides, and no specific 
side was specified;  assuming `clt' side
last/srv.1.log:warning: failed to read log file, skipping

So either '--side all' doesn't work correctly (if '--side all' is 
designed to be used for logs that have infor from both sides, not for 
logs that have info from any but one side), or whole polygraph-ltrace 
works incorrectly, assuming that there will be one-side logs in input.
Anyway, this is minor bug.

>> Best wishes,
>> Pavel
>>
>> On 07/17/2013 07:43 PM, Franck Youssef wrote:
>>> 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?
>>>
> This is definitely a bug, reporter should never crash.  Do all client
> and server hosts use the same workload?  Can you please provide a
> backtrace for the reporter crash (dump core, run "gdb polygraph-reporter
> core" command, run "bt" command)?  Or even better, would it be possible
> for you to give us the binary logs (privately)?  That would make it much
> easier for us to triage the bug.
>
> Regards,
>    Dmitry
>
>>> Thank you a lot for your explanations.
>>>
>>> Cheers,
>>>
>>> Franck
>> _______________________________________________
>> Users mailing list
>> Users at web-polygraph.org
>> http://www.web-polygraph.org/mailman/listinfo/users