Hi List,
is there a way to trigger some sort of automatic device rediscovery? We recently changed a lot of ports on our cisco 4500 series switches to trunk mode and although this happened more than 2 weeks ago, NAV still does not reflect these new settings in the switch overview/IP Device Info. Is NAV even supposed to see these kind of changes or might I be hitting a bug? We are currently using NAV 3.5.4 - I know its not the latest release but at least its close to it ;-) On top of that I couldnt find any hints regarding this problem in the latest changelog.
On Mon, 15 Mar 2010 11:39:13 +0100 Rudolph Bott rb@knurps.org wrote:
Hi List,
is there a way to trigger some sort of automatic device rediscovery? We recently changed a lot of ports on our cisco 4500 series switches to trunk mode and although this happened more than 2 weeks ago, NAV still does not reflect these new settings in the switch overview/IP Device Info. Is NAV even supposed to see these kind of changes or might I be hitting a bug? We are currently using NAV 3.5.4 - I know its not the latest release but at least its close to it ;-) On top of that I couldnt find any hints regarding this problem in the latest changelog.
This sounds like a bug; NAV should have discovered those changes within six hours of them taking place.
1. Does your getDeviceData-stderr.log file contain any conspicuous error messages?
2. Are there error messages in getDeviceData.log related to the switches that aren't getting updated?
3. Does it help to restart getDeviceData?
Hi Morten,
apparantly getDeviceData wasnt running at all - is it supposed to be started via cron?
This is what I found at the end of getDeviceData.log:
=== SNIP === ov 27 15:34:38 2009 getDeviceData null-3-DATABASE-QUERY Statement caused SQLException: SELECT eventqid,source,target,deviceid,netboxid,subid,time,eventtypeid,state,value,severity,var,val FROM eventq LEFT JOIN eventqvar USING (eventqid) WHERE eventqid > 0 AND target IN ('getDeviceData') ORDER BY eventqid Nov 27 15:34:38 2009 getDeviceData null-3-DATABASE-QUERY Exception details: org.postgresql.util.PSQLException: An I/O error occured while sending to the backend. Exception: java.net.SocketException: Broken pipe Stack Trace: java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123) at org.postgresql.core.PGStream.flush(PGStream.java:508) at org.postgresql.core.v3.QueryExecutorImpl.sendSync(QueryExecutorImpl.java:675) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:190) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:337) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:236) at no.ntnu.nav.Database.Database.query(Database.java:781) at no.ntnu.nav.Database.Database.query(Database.java:751) at no.ntnu.nav.event.EventQMonitorTask.run(EventQ.java:252) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) End of Stack Trace
Nov 27 15:34:38 2009 getDeviceData null-6-DATABASE-QUERY Exception cause: null Nov 27 15:34:38 2009 getDeviceData null-6-DATABASE-QUERY Exception error code: 0 Nov 27 15:34:38 2009 getDeviceData null-6-DATABASE-QUERY Exception SQLState: 08006 Nov 27 15:34:38 2009 getDeviceData null-6-DATABASE-QUERY Next exception in chain: null Nov 27 15:34:38 2009 getDeviceData null-4-DATABASE-QUERY Database is not connected. Nov 27 15:34:38 2009 getDeviceData null-3-DATABASE-QUERY Database reconnect failed Nov 27 15:34:38 2009 getDeviceData null-4-DATABASE-QUERY Attempting to reconnect in 10000 ms
=== SNIP ===
Maybe the database got restarted during a script-run (that would explain the I/O error). I ran getDeviceData.sh manually from the bin-folder and all the configurations are up to date now.
On Tue, 16 Mar 2010 10:57:36 +0100, Morten Brekkevold morten.brekkevold@uninett.no wrote:
On Mon, 15 Mar 2010 11:39:13 +0100 Rudolph Bott rb@knurps.org wrote:
Hi List,
is there a way to trigger some sort of automatic device rediscovery? We recently changed a lot of ports on our cisco 4500 series switches to trunk mode and although this happened more than 2 weeks ago, NAV still does
not
reflect these new settings in the switch overview/IP Device Info. Is
NAV
even supposed to see these kind of changes or might I be hitting a bug? We are currently using NAV 3.5.4 - I know its not the latest release but
at
least its close to it ;-) On top of that I couldnt find any hints regarding this problem in the latest changelog.
This sounds like a bug; NAV should have discovered those changes within six hours of them taking place.
Does your getDeviceData-stderr.log file contain any conspicuous error messages?
Are there error messages in getDeviceData.log related to the switches that aren't getting updated?
Does it help to restart getDeviceData?
On Tue, 16 Mar 2010 12:47:40 +0100 Rudolph Bott rb@knurps.org wrote:
Hi Morten,
apparantly getDeviceData wasnt running at all - is it supposed to be started via cron?
No, getDeviceData is a daemon. Check the status of all NAV daemons and cron jobs by issuing the "nav status" command. If getDeviceData is having I/O problems with the database, it can be restarted by issuing "nav restart getDeviceData".
Maybe the database got restarted during a script-run (that would explain the I/O error). I ran getDeviceData.sh manually from the bin-folder and all the configurations are up to date now.
Loss of database connectivity pretty much explains the problems you were experiencing, yes.
-
Morten Brekkevold -
Rudolph Bott