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 I
> don'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



--
Att.
Bruno Galindro da Costa