Nav-users September 2007

nav-users@lister.sikt.no

2 participants
3 discussions

Announcement: NAV 3.3.0 RC1 released
by morten.brekkevold＠uninett.no 18 Sep '07

18 Sep '07

A release candidate of NAV 3.3.0 is now available for download at SourceForge, see http://sourceforge.net/projects/nav :-) This is mainly a feature release, but many bugs have also been fixed. We kindly ask you to give us feedback, both positive and negative, on the mailing list if you decide to test the release candidate. We will wait about 10 days to see what issues may arise concering this candidate, before we release the final 3.3.0 version. The Debian package maintainer, Morten Werner Olsen, is currently in the final stages of testing a Debian Etch package of NAV 3.2.2, and will proceed to package NAV 3.3.0 when this work is finished. -- mvh Morten Brekkevold UNINETT

1 0

Re: rrdtool and other problems on Suse 10.2
by morten.brekkevold＠uninett.no 07 Sep '07

07 Sep '07

Mels wrote, On 09/06/2007 09:01 PM: > Hi all, Hi Mels. > I started this week with a clean system, installing nav on Suse 10.2 > > There was a problem with connecting to a remote database, for the time i > use the local database, witch is OK for nav. Ok, if you need some tips on connecting to a remote database, please don't hesitate to ask :) > I get 3 problems: > 1 I installed py-rrdtool-1.0b1, with the installation off > py-rrdtool-0.2.1 I get a error: > building 'rrdtool._rrdtool' extension > gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -march=i586 -mtune=i686 > -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -fPIC > -I/usr/local/include -I/usr/include/python2.5 -c src/_rrdtoolmodule.c -o > build/temp.linux-i686-2.5/src/_rrdtoolmodule.o > src/_rrdtoolmodule.c: In function ?PyRRD_graph?: > src/_rrdtoolmodule.c:239: error: too few arguments to function ?rrd_graph? > error: command 'gcc' failed with exit status 1 I did not recognize the version numbers you mentioned, and checking up on things seems to reveal that there is some confusion about which python-rrdtool library to use. Apparently there are two very similar libraries in existance: One is distributed alongside rrdtool itself, and one is available at http://sourceforge.net/projects/py-rrdtool . The one currently in use by us on our dev server is the python-rrd library that comes with rrdtool itself; in Debian this package is called python-rrd. The package also follows the same version numbering scheme as rrdtool, which means that the latest version of it is >= 1.2. Unless Suse 10.2 prepackages this alongside its regular rrdtool package, you'll need to get hold of the rrdtool source code instead. This would also be the best way to make sure the python library version matches the rrdtool library version. > 2 and 3 pping and servicemon failed to start, I tried a nav start pping > servicemon a couple of time, also a start separate. > but they whon't start. I changed DEBUG_LEVEL = 6 in nav.conf, but can't > find any reason in the log files. The DEBUG_LEVEL in nav.conf only sets debug levels for the Java subsystems (i.e. getDeviceData, eventEngine, getBoksMacs, networkDiscovery). The pping and servicemon processes have their own debug level settings in their respective config files. That said, pping and servicemon share much of the same code base, and they are both known to have startup difficulties. We have yet to investigate what causes the problem, but usually, when one experiences startup problems with these two, it helps to retry it several times. -- mvh Morten Brekkevold UNINETT >From mels at mels-kooijman.nl Fri Sep 7 21:12:33 2007 From: mels at mels-kooijman.nl (Mels) Date: Fri Sep 7 20:12:23 2007 Subject: [Nav-users] Re: rrdtool and other problems on Suse 10.2 In-Reply-To: <46E13E6C.3020600(a)uninett.no> References: <200709031022.52942.barbieri.marco(a)unimore.it> <46DFC491.4070702(a)uninett.no> <46E04EA1.3010906(a)mels-kooijman.nl> <46E13E6C.3020600(a)uninett.no> Message-ID: <46E19491.2050804(a)mels-kooijman.nl> Thanks for your reply. I removed the rrdtool, wich was from the suse media. I compiled RRDtool 1.2.15 (the suse version was the same) and install it. I recompiled psycopg-1.1.21, the cronjob produced a error. After this restartapache,tomcat,postgresql and nav Even pping and servicemon started the first time. No errormail from the cronjobs, everythings looks fine, til i login in nav: error File "/usr/local/nav/lib/python/nav/web/state.py", line 250, in __new__ raise e Maybe i have to rebuild more modules? Mels Morten Brekkevold wrote: > Mels wrote, On 09/06/2007 09:01 PM: > > >> Hi all, >> > > Hi Mels. > > >> I started this week with a clean system, installing nav on Suse 10.2 >> >> There was a problem with connecting to a remote database, for the time i >> use the local database, witch is OK for nav. >> > > Ok, if you need some tips on connecting to a remote database, please don't > hesitate to ask :) > > >> I get 3 problems: >> 1 I installed py-rrdtool-1.0b1, with the installation off >> py-rrdtool-0.2.1 I get a error: >> building 'rrdtool._rrdtool' extension >> gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -march=i586 -mtune=i686 >> -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -fPIC >> -I/usr/local/include -I/usr/include/python2.5 -c src/_rrdtoolmodule.c -o >> build/temp.linux-i686-2.5/src/_rrdtoolmodule.o >> src/_rrdtoolmodule.c: In function ?PyRRD_graph?: >> src/_rrdtoolmodule.c:239: error: too few arguments to function ?rrd_graph? >> error: command 'gcc' failed with exit status 1 >> > > I did not recognize the version numbers you mentioned, and checking up on > things seems to reveal that there is some confusion about which python-rrdtool > library to use. Apparently there are two very similar libraries in existance: > One is distributed alongside rrdtool itself, and one is available at > http://sourceforge.net/projects/py-rrdtool . > > The one currently in use by us on our dev server is the python-rrd library > that comes with rrdtool itself; in Debian this package is called python-rrd. > The package also follows the same version numbering scheme as rrdtool, which > means that the latest version of it is >= 1.2. Unless Suse 10.2 prepackages > this alongside its regular rrdtool package, you'll need to get hold of the > rrdtool source code instead. This would also be the best way to make sure the > python library version matches the rrdtool library version. > > >> 2 and 3 pping and servicemon failed to start, I tried a nav start pping >> servicemon a couple of time, also a start separate. >> but they whon't start. I changed DEBUG_LEVEL = 6 in nav.conf, but can't >> find any reason in the log files. >> > > The DEBUG_LEVEL in nav.conf only sets debug levels for the Java subsystems > (i.e. getDeviceData, eventEngine, getBoksMacs, networkDiscovery). The pping > and servicemon processes have their own debug level settings in their > respective config files. > > That said, pping and servicemon share much of the same code base, and they are > both known to have startup difficulties. We have yet to investigate what > causes the problem, but usually, when one experiences startup problems with > these two, it helps to retry it several times. > > > >From mels at mels-kooijman.nl Fri Sep 7 21:37:17 2007 From: mels at mels-kooijman.nl (Mels) Date: Fri Sep 7 20:38:51 2007 Subject: [Nav-users] Re: rrdtool and other problems on Suse 10.2 In-Reply-To: <46E19491.2050804(a)mels-kooijman.nl> References: <200709031022.52942.barbieri.marco(a)unimore.it> <46DFC491.4070702(a)uninett.no> <46E04EA1.3010906(a)mels-kooijman.nl> <46E13E6C.3020600(a)uninett.no> <46E19491.2050804(a)mels-kooijman.nl> Message-ID: <46E19A5D.7050305(a)mels-kooijman.nl> That problem solved, was ownership of a few files. Everything looks fine, start playing with nav. Mels Mels wrote: > Thanks for your reply. > > I removed the rrdtool, wich was from the suse media. > I compiled RRDtool 1.2.15 (the suse version was the same) and install it. > I recompiled psycopg-1.1.21, the cronjob produced a error. > > After this restartapache,tomcat,postgresql and nav > Even pping and servicemon started the first time. > > No errormail from the cronjobs, everythings looks fine, til i login in > nav: > > error > > File "/usr/local/nav/lib/python/nav/web/state.py", line 250, in __new__ > raise e > > Maybe i have to rebuild more modules? > > Mels > > Morten Brekkevold wrote: >> Mels wrote, On 09/06/2007 09:01 PM: >> >> >>> Hi all, >>> >> >> Hi Mels. >> >> >>> I started this week with a clean system, installing nav on Suse 10.2 >>> >>> There was a problem with connecting to a remote database, for the >>> time i >>> use the local database, witch is OK for nav. >>> >> >> Ok, if you need some tips on connecting to a remote database, please >> don't >> hesitate to ask :) >> >> >>> I get 3 problems: >>> 1 I installed py-rrdtool-1.0b1, with the installation off >>> py-rrdtool-0.2.1 I get a error: >>> building 'rrdtool._rrdtool' extension >>> gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -march=i586 -mtune=i686 >>> -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -fPIC >>> -I/usr/local/include -I/usr/include/python2.5 -c >>> src/_rrdtoolmodule.c -o >>> build/temp.linux-i686-2.5/src/_rrdtoolmodule.o >>> src/_rrdtoolmodule.c: In function ?PyRRD_graph?: >>> src/_rrdtoolmodule.c:239: error: too few arguments to function >>> ?rrd_graph? >>> error: command 'gcc' failed with exit status 1 >>> >> >> I did not recognize the version numbers you mentioned, and checking >> up on >> things seems to reveal that there is some confusion about which >> python-rrdtool >> library to use. Apparently there are two very similar libraries in >> existance: >> One is distributed alongside rrdtool itself, and one is available at >> http://sourceforge.net/projects/py-rrdtool . >> >> The one currently in use by us on our dev server is the python-rrd >> library >> that comes with rrdtool itself; in Debian this package is called >> python-rrd. >> The package also follows the same version numbering scheme as >> rrdtool, which >> means that the latest version of it is >= 1.2. Unless Suse 10.2 >> prepackages >> this alongside its regular rrdtool package, you'll need to get hold >> of the >> rrdtool source code instead. This would also be the best way to make >> sure the >> python library version matches the rrdtool library version. >> >> >>> 2 and 3 pping and servicemon failed to start, I tried a nav start >>> pping >>> servicemon a couple of time, also a start separate. >>> but they whon't start. I changed DEBUG_LEVEL = 6 in nav.conf, but can't >>> find any reason in the log files. >>> >> >> The DEBUG_LEVEL in nav.conf only sets debug levels for the Java >> subsystems >> (i.e. getDeviceData, eventEngine, getBoksMacs, networkDiscovery). >> The pping >> and servicemon processes have their own debug level settings in their >> respective config files. >> >> That said, pping and servicemon share much of the same code base, and >> they are >> both known to have startup difficulties. We have yet to investigate >> what >> causes the problem, but usually, when one experiences startup >> problems with >> these two, it helps to retry it several times. >> >> >> > _______________________________________________ > nav-users mailing list > nav-users(a)itea.ntnu.no > http://mailman.itea.ntnu.no/mailman/listinfo/nav-users > >From ghitzacatalin at yahoo.com Sun Sep 9 14:33:57 2007 From: ghitzacatalin at yahoo.com (Gheorghe Limboi) Date: Sun Sep 9 22:34:06 2007 Subject: [Nav-users] IP address scope - graphical view / Traffic map load Message-ID: <362473.55698.qm(a)web50011.mail.re2.yahoo.com> Hi, regarding.. > 2. On traffic map -- there is no load on the link (Load: <0.01% No Data) > but when I follow the link (right clik - Load - this open the correct > cricket graph .. and thre is load on the link ) I fond this in tomcat server logs: SQLException for update statement: SELECT netboxid,descr,name,path,filename,key,value FROM rrd_file JOIN rrd_datasource USING(rrd_fi leid) WHERE subsystem='cricket' AND descr IN ('ifOutOctets','ifInOctets') AND ((key='gwport' AND value IN (33,24,10))) org.postgresql.util.PSQLException: ERROR: IN types character varying and integer cannot be matched This seems to be related to postgresql 8.2.x restriction ( I have postgresql-8.2.4 installed). Is there any work around or the only way is to downgrade to a lower version of postgresql tx, Gheorghe ----- Original Message ---- From: Morten Brekkevold <morten.brekkevold(a)uninett.no> To: Gheorghe Limboi <ghitzacatalin(a)yahoo.com> Cc: nav-users(a)itea.ntnu.no Sent: Friday, August 31, 2007 8:40:04 AM Subject: Re: [Nav-users] IP address scope - graphical view / Traffic map load Gheorghe Limboi wrote, On 24-08-2007 22:42: > Hi, Hi Gheorghe! > 1. Reports - > IP address scope - graphical view > > the olny result i get on the page is: 0326496128160192224 What exactly do you mean by "result"? Does the page consist of only this plaintext number and nothing else? > 2. On traffic map -- there is no load on the link (Load: <0.01% No Data) > but when I follow the link (right clik - Load - this open the correct > cricket graph .. and thre is load on the link ) > > > Any iddeas what I'm missing? You don't specify which version of NAV you are running, but I'm sure you're not using anything earlier than 3.1.1. We fixed a long standing problem with missing link load in the Traffic Map in that version, but you may be experiencing a different problem. The Traffic Map applet requests its data from the vPServer servlet running in the Tomcat container; the vPServer component calls the vprrd.py script to retrieve the actual RRD data, and something might have gone wrong during the calling of this script. I have to go now, but I will get back to you on this later, when I figure out whether there are any logs you can check to find the problem. -- mvh Morten Brekkevold UNINETT ____________________________________________________________________________________ Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545469 >From morten.brekkevold at uninett.no Tue Sep 11 14:41:33 2007 From: morten.brekkevold at uninett.no (Morten Brekkevold) Date: Tue Sep 11 13:41:37 2007 Subject: [Nav-users] IP address scope - graphical view / Traffic map load In-Reply-To: <362473.55698.qm(a)web50011.mail.re2.yahoo.com> References: <362473.55698.qm(a)web50011.mail.re2.yahoo.com> Message-ID: <46E67EED.1090604(a)uninett.no> Gheorghe Limboi wrote, On 09-09-2007 22:33: > I fond this in tomcat server logs: > > SQLException for update statement: SELECT netboxid,descr,name,path,filename,key,value FROM rrd_file JOIN rrd_datasource USING(rrd_fi > leid) WHERE subsystem='cricket' AND descr IN ('ifOutOctets','ifInOctets') AND ((key='gwport' AND value IN (33,24,10))) > org.postgresql.util.PSQLException: ERROR: IN types character varying and integer cannot be matched Ah, that explains why you're not getting any load data on your traffic map! > This seems to be related to postgresql 8.2.x restriction ( I have > postgresql-8.2.4 installed). Is there any work around or the only way is > to downgrade to a lower version of postgresql I don't see any workaround other than downgrading PostgreSQL :-( I've just looked at the code that creates the offending SQL statement - it looks hairy, but I'll try to fix it. I can post the patch here when it's done, if you like. -- mvh Morten Brekkevold UNINETT >From morten.brekkevold at uninett.no Tue Sep 11 14:45:30 2007 From: morten.brekkevold at uninett.no (Morten Brekkevold) Date: Tue Sep 11 13:47:41 2007 Subject: [Nav-users] Re: rrdtool and other problems on Suse 10.2 In-Reply-To: <46E19A5D.7050305(a)mels-kooijman.nl> References: <200709031022.52942.barbieri.marco(a)unimore.it> <46DFC491.4070702(a)uninett.no> <46E04EA1.3010906(a)mels-kooijman.nl> <46E13E6C.3020600(a)uninett.no> <46E19491.2050804(a)mels-kooijman.nl> <46E19A5D.7050305(a)mels-kooijman.nl> Message-ID: <46E67FDA.3030101(a)uninett.no> Mels wrote, On 07-09-2007 20:37: > That problem solved, was ownership of a few files. > > Everything looks fine, start playing with nav. Great! Just give a shout if there are any more problems :) -- mvh Morten Brekkevold UNINETT >From marco.barbieri at unimore.it Mon Sep 17 15:41:30 2007 From: marco.barbieri at unimore.it (Marco Barbieri) Date: Mon Sep 17 14:41:39 2007 Subject: [Nav-users] NAV & VMware Message-ID: <200709171441.30621.marco.barbieri(a)unimore.it> Hi all, since i'm running my copies of NAV inside VMware machines i'm here to ask if could be of any help to the developing staff do give them a copy of an abstract machine. The main advantage that i could see would be skipping through the "Installing on Centos 4.4" faq, reconfiguration would be limited at network parameters, the generation of SSL certificate and... and what? Let me know if this sounds interesting. Best reguards, Marco Barbieri. -- Marco Barbieri - CeSIA - 059-2055218

1 0

Centos 5 and NAV 3.2.2
by barbieri.marco＠unimore.it 03 Sep '07

03 Sep '07

Hi, first of all i'm trying to run NAV 3.2.2 on a Centos 5 and i know it's not supported, but with really liitle tweaking the system seem to be up and running, despite the problem i've always had with my HP9304m that i've already posted about (answer pending...). I get some errors from: Cron <navcron@nav> $BINDIR/getBoksMacs.sh $NUM_THREADS the body of the message is at the end of this msg, there's something i can do to fix it or the set of libs that comes with Centos5 is too much different to let NAV work as it is? Thanks for reading and my best regards, Marco barbieri. ---Body--- org.postgresql.util.PSQLException: This statement has been closed. at org.postgresql.jdbc2.AbstractJdbc2Statement.checkClosed(postgresql-jdbc-8.1.407.jar.so) at org.postgresql.jdbc2.AbstractJdbc2Statement.getUpdateCount(postgresql-jdbc-8.1.407.jar.so) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(postgresql-jdbc-8.1.407.jar.so) at no.ntnu.nav.Database.Database.update(Database.java:1004) at no.ntnu.nav.Database.Database.insert(Database.java:928) at QueryBoks.runCamQueue(QueryBoks.java:1659) at QueryBoks.processMacEntry(QueryBoks.java:977) at QueryBoks.run(QueryBoks.java:266) SQLException for update statement: INSERT INTO cam (netboxid,sysname,ifindex,module,port,mac,start_time) VALUES ('6','rett-mo-hp.unimo.it','128','0','28','0011d80d2cde',NOW()) org.postgresql.util.PSQLException: This statement has been closed. at org.postgresql.jdbc2.AbstractJdbc2Statement.checkClosed(postgresql-jdbc-8.1.407.jar.so) at org.postgresql.jdbc2.AbstractJdbc2Statement.getUpdateCount(postgresql-jdbc-8.1.407.jar.so) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(postgresql-jdbc-8.1.407.jar.so) at no.ntnu.nav.Database.Database.update(Database.java:1004) at no.ntnu.nav.Database.Database.insert(Database.java:928) at QueryBoks.runCamQueue(QueryBoks.java:1659) at QueryBoks.processMacEntry(QueryBoks.java:977) at QueryBoks.run(QueryBoks.java:266) ---Body--- -- Marco Barbieri - CeSIA - 059-2055218 >From morten.brekkevold at uninett.no Thu Sep 6 11:35:14 2007 From: morten.brekkevold at uninett.no (Morten Brekkevold) Date: Thu Sep 6 10:35:38 2007 Subject: [Nav-users] Problem with NAV 3.2.2 and Hp 9304M - WRONG DATA - SORRY In-Reply-To: <200708310840.46033.barbieri.marco(a)unimore.it> References: <200708310840.46033.barbieri.marco(a)unimore.it> Message-ID: <46DFBBC2.2050000(a)uninett.no> Marco Barbieri wrote, On 31-08-2007 08:40: > Hi again, > i'm sorry i've posted the wrong data, in the previous post you can find a > HP5412zl that NAV detects well. > > Here there's the data about HP9304M (it's marked HP but it's a Foundry > machine) that has the problem, it's a chassis with 4 slots, 3 of them are > loaded with 8 gbic sockets boards. Given the OID compatibility report you sent, NAV should be able to detect the ports on this routing switch; the ports are detected using standard mibs. Yet you say that _no_ ports are detected? If that is so, I would like to see what getDeviceData.log says when it collects from this device. When it comes to modules, I must admit that NAV's support for HP equipment is lacking in several respects. The HP support was written and tested using the equipment that was available at the Norwegian University of Science and Technology at the time, and these were all HP SwitchStacks. Consequently, NAV only recognizes virtual stacking in HP equipment, and cannot at all recognize modules in your HP chassis. It is in our plans to implement more generic module support through interpreting the ENTITY-MIB. I'm guessing your HP9304M presents a fairly correct view of its physical contents through its entPhysicalTable? Since I have no access to a 9304M myself, but am planning to code the ENTITY-MIB support, I would greatly appreciate it if you could provide me with the output of this table from your device; running this command on your NAV server should do it: snmptable -Ci -Cb -v2c -c <community> <ip> entPhysicalTable -- mvh Morten Brekkevold UNINETT >From morten.brekkevold at uninett.no Thu Sep 6 12:12:49 2007 From: morten.brekkevold at uninett.no (Morten Brekkevold) Date: Thu Sep 6 11:13:05 2007 Subject: [Nav-users] Centos 5 and NAV 3.2.2 In-Reply-To: <200709031022.52942.barbieri.marco(a)unimore.it> References: <200709031022.52942.barbieri.marco(a)unimore.it> Message-ID: <46DFC491.4070702(a)uninett.no> Marco Barbieri wrote, On 03-09-2007 10:22: > first of all i'm trying to run NAV 3.2.2 on a Centos 5 and i know it's not > supported, That depends on what you mean by "supported" :) We do not guaruantee support to anyone, but you should be able to have NAV up and run on any Linux distro. The most common obstacle seems to be when some software that NAV depends on comes out with a new version that breaks some backwards compatibility. > I get some errors from: > > Cron <navcron@nav> $BINDIR/getBoksMacs.sh $NUM_THREADS > > the body of the message is at the end of this msg, there's something i can do > to fix it or the set of libs that comes with Centos5 is too much different to > let NAV work as it is? > > Thanks for reading and my best regards, Marco barbieri. > > ---Body--- > org.postgresql.util.PSQLException: This statement has been closed. > at > org.postgresql.jdbc2.AbstractJdbc2Statement.checkClosed(postgresql-jdbc-8.1.407.jar.so) [...] I think I've seen this before, and it happened when we upgraded our PostgreSQL JDBC driver to version 8.1. I'm not sure what changed, since the API should remain the same - only the driver should work better against PostgreSQL 8.1. I assume that your CentOS installation runs the PostgreSQL 8.1 server as well? Our temporary workaround was to downgrade the JDBC driver to the 7.4 version. You could try and see if that works. If CentOS 5 doesn't provide that version of the driver, you can get it from http://jdbc.postgresql.org/ -- mvh Morten Brekkevold UNINETT >From mels at mels-kooijman.nl Thu Sep 6 22:01:53 2007 From: mels at mels-kooijman.nl (Mels) Date: Thu Sep 6 21:02:09 2007 Subject: [Nav-users] Centos 5 and NAV 3.2.2 In-Reply-To: <46DFC491.4070702(a)uninett.no> References: <200709031022.52942.barbieri.marco(a)unimore.it> <46DFC491.4070702(a)uninett.no> Message-ID: <46E04EA1.3010906(a)mels-kooijman.nl> Hi all, I started this week with a clean system, installing nav on Suse 10.2 There was a problem with connecting to a remote database, for the time i use the local database, witch is OK for nav. I get 3 problems: 1 I installed py-rrdtool-1.0b1, with the installation off py-rrdtool-0.2.1 I get a error: building 'rrdtool._rrdtool' extension gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -fPIC -I/usr/local/include -I/usr/include/python2.5 -c src/_rrdtoolmodule.c -o build/temp.linux-i686-2.5/src/_rrdtoolmodule.o src/_rrdtoolmodule.c: In function ?PyRRD_graph?: src/_rrdtoolmodule.c:239: error: too few arguments to function ?rrd_graph? error: command 'gcc' failed with exit status 1 from the cron I get a mail with the next text: File "/usr/local/nav/bin/thresholdMon.py", line 46, in <module> from nav.rrd import presenter File "/usr/local/nav/lib/python/nav/rrd/presenter.py", line 54, in <module> import rrdtool ImportError: dynamic module does not define init function (initrrdtool) 2 and 3 pping and servicemon failed to start, I tried a nav start pping servicemon a couple of time, also a start separate. but they whon't start. I changed DEBUG_LEVEL = 6 in nav.conf, but can't find any reason in the log files. Mels

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Nav-users September 2007