Nut upsdev - May 2009 - timestamped debug output (was: upsd flapping in the breeze)

2009/5/16 Arnaud Quette <aquette.dev at gmail.com>
>
>
> 2009/5/7 Daniel O'Connor <doconnor at gsoft.com.au>
>
>> On Wed, 6 May 2009, Arnaud Quette wrote:
>> > I think I've found something, but I would need an upsd debug
output
>> > (level 3) to see what going on the state socket.
>>
>> I've attached a log for you.
>>
>> > A few more questions:
>> > - would you be able to test a patch?
>>
>> Yep.
>>
>
> attached, with explanation.
> can you also test a real disconnection of the serial cable, and report back
> if everything is ok?
>
as a side note, debug timestamping is now available:
ie: mge-shut -DDDT -a ...

Network UPS Tools - MGE UPS SYSTEMS/SHUT driver 0.68 (2.4.1-1840:1845M)
14:27:25: debug level is '3'
14:27:25: entering upsdrv_initups()
14:27:25: entering setline(1)
14:27:25: entering shut_ups_start()
...

This is effective for upsd, upsmon, upsdrvctl and the drivers by using
"-T".
The best, as told in the manpages, is to use it in conjunction with the
debug flags (ie -D...)
This should help out in troubleshooting timeframe problems.

cheers,
Arnaud
-- 
Linux / Unix Expert R&D - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20090518/d85b39cb/attachment.htm>

Citeren Arnaud Quette <aquette.dev op gmail.com>:
> as a side note, debug timestamping is now available:
> ie: mge-shut -DDDT -a ...
>
> Network UPS Tools - MGE UPS SYSTEMS/SHUT driver 0.68 (2.4.1-1840:1845M)
> 14:27:25: debug level is '3'
> 14:27:25: entering upsdrv_initups()
> 14:27:25: entering setline(1)
> 14:27:25: entering shut_ups_start()
> ...
>
> This is effective for upsd, upsmon, upsdrvctl and the drivers by using
"-T".
> The best, as told in the manpages, is to use it in conjunction with the
> debug flags (ie -D...)
> This should help out in troubleshooting timeframe problems.
Brilliant! I've found myself adding timestamps (and removing them  
again) several times. It probably would be much better to enable this  
everywhere. Two remarks:

1) I wouldn't mind enabling this by default in upsdebugx() and friends  
when debugging is enabled. In that case, the changes would be limited  
to common.c

2) It might be better to use gettimeofday() instead if time() here. A  
one second resolution might not provide enough granularity to be  
really useful, except for finding timeouts. If we however add a  
millisecond resolution, we might also get an idea how long certain  
actions take, to see if it is worth optimizing things.

Best regards, Arjen
-- 
Please keep list traffic on the list