On Tue, 19 Feb 2013 11:29:19 +0100 Ingeborg Hellemo ingeborg.hellemo@uit.no wrote:
morten.brekkevold@uninett.no said:
You are using NetworkX 1.6, while NAV was developed on NetworkX 1.1.
You are soooo 2010! I'll downgrade. On FreeBSD I can choose between 1.0.1 and 1.2. Go figure...
We can still try to catch the exception, though, if you would like to file a bug report.
That did the trick - today. I restarted all the NAV services yesterday while trying to figure out the error and pping did not then find the servers. But today - with the moon in first quarter - it worked.
Given the correct pping log level, it should be obvious when it can and cannot get a ping response from a device.
eventenginde was logging with the default level (which is..?)
I believe the default of Python's logging system is the WARNING level. Some of the NAV daemons are inconsistent here, and provide a way of configuring the default base level in its own config file, and only letting `logging.conf` override it. The two exceptions are the ancient code bases of pping and servicemon, which use a homegrown logging system (I believe they were written before Python grew a standard logging library).
and except a couple of hobbitServiceDown/Up-messages (which shows that the servers became available after a few minutes) I find no log lines about the servers after the NetworkXNoPath. The servers were never really down, but something happened with the network.
And as you know, to NAV it doesn't matter much if they were really down, only whether they were ping-reachable.
I have upped the log level for eventengine. Is there a way to up the log level for all the services at the same time or is it one line per service?
You could add "root=INFO" or "nav=INFO", but I would advise against it as a permanent solution. Some of the cron jobs will log to stdout/stderr instead of a file, and might spam you to death.