If there was a problem before you set the DEBUG level, then it must have been a different problem than the one you sent a traceback for. The specific traceback you sent showed the error to occur when attempting to debug-log the data structures that were being saved to the database.
Yes, you are right. This is the message that apeared in logs and I was thinked that is was an error... my mistake sorry... What this message means?
2014-07-03 10:26:32,806 [WARNING timestamps.timestampchecker] [topo 150.162.250.252] 'lldp': retrieved empty timestamp
As long as the problem exists in IPy, all we can do is think of some
workaround in NAV, at best. Maybe report a bug to the IPy guys. My mitigation tip is still valid though - you will likely never need to have debug level set for "nav.ipdevpoll.jobs.jobhandler-queue", unless a developer asks for it specifically :)
Ok!
2014-07-08 4:51 GMT-03:00 Morten Brekkevold morten.brekkevold@uninett.no:
On Mon, 7 Jul 2014 08:27:08 -0300 Bruno Galindro da Costa < bruno.galindro@gmail.com> wrote:
Morten,
I've upgraded the package and now the problem is other. Another thing
is
that the previous error was ocurring even running NAV without DEBUG
setting
in nav.ipdevpoll.jobs.jobhandler at /etc/nav/logging.conf. I've put it in DEBUG to provide more information about this error before starting this tread.
If there was a problem before you set the DEBUG level, then it must have been a different problem than the one you sent a traceback for. The specific traceback you sent showed the error to occur when attempting to debug-log the data structures that were being saved to the database.
This new problem seems to ocurring only with DEBUG setting... but Idon't know if this is true or false. Can you confirm it for me please?
Ah, yes. *headslap*. I was too quick when saying the bug was fixed in a newer IPy. They changed the code, but the comparison problem isn't really fixed. You still cannot compare IP objects to arbitrary other objects; the only difference is the type of exception raised when you attempt to. This isn't really good behavior for a Python object.
Even so, the only reason IP objects are being compared to non-IP objects is because Python's pprint insists on sorting dictionary keys for pretty-printing.
As long as the problem exists in IPy, all we can do is think of some workaround in NAV, at best. Maybe report a bug to the IPy guys. My mitigation tip is still valid though - you will likely never need to have debug level set for "nav.ipdevpoll.jobs.jobhandler-queue", unless a developer asks for it specifically :)
-- Morten Brekkevold UNINETT