Ntop with Pfsense 1.2.3
-
I did some reading about this and it looks like ntop cannot create the directory because it does not have permission to do so. So, you need to do chmod -R 777 /var/db/ntop/rrd
Now, it will create the directory… however, there are other problems. Check this out:
# ntop Tue Jan 19 18:55:54 2010 NOTE: Interface merge enabled by default Tue Jan 19 18:55:54 2010 Initializing gdbm databases Tue Jan 19 18:55:54 2010 ntop will be started as user nobody Tue Jan 19 18:55:54 2010 ntop v.3.3.8 Tue Jan 19 18:55:54 2010 Configured on Dec 4 2008 15:19:28, built on Dec 4 2008 15:19:59. Tue Jan 19 18:55:54 2010 Copyright 1998-2007 by Luca Deri <deri@ntop.org>Tue Jan 19 18:55:54 2010 Get the freshest ntop from http://www.ntop.org/ Tue Jan 19 18:55:54 2010 NOTE: ntop is running from 'ntop' Tue Jan 19 18:55:54 2010 NOTE: (but see warning on man page for the --instance parameter) Tue Jan 19 18:55:54 2010 NOTE: ntop libraries are in '/usr/local/lib' Tue Jan 19 18:55:54 2010 Initializing ntop Tue Jan 19 18:55:54 2010 No patterns to load: protocol guessing disabled. Tue Jan 19 18:55:54 2010 Checking fxp0 for additional devices Tue Jan 19 18:55:54 2010 Resetting traffic statistics for device fxp0 Tue Jan 19 18:55:54 2010 Initializing device fxp0 (0) Tue Jan 19 18:55:54 2010 DLT: Device 0 [fxp0] is 1, mtu 1514, header 14 Tue Jan 19 18:55:54 2010 Checking fxp1 for additional devices Tue Jan 19 18:55:54 2010 Resetting traffic statistics for device fxp1 Tue Jan 19 18:55:54 2010 Initializing device fxp1 (1) Tue Jan 19 18:55:54 2010 DLT: Device 1 [fxp1] is 1, mtu 1514, header 14 Tue Jan 19 18:55:54 2010 Checking fxp2 for additional devices Tue Jan 19 18:55:54 2010 Resetting traffic statistics for device fxp2 Tue Jan 19 18:55:54 2010 Initializing device fxp2 (2) Tue Jan 19 18:55:54 2010 DLT: Device 2 [fxp2] is 1, mtu 1514, header 14 Tue Jan 19 18:55:54 2010 Initializing gdbm databases Tue Jan 19 18:55:54 2010 VENDOR: Loading MAC address table. Tue Jan 19 18:55:54 2010 VENDOR: Checking for MAC address table file Tue Jan 19 18:55:54 2010 VENDOR: File '/usr/local/etc/ntop/specialMAC.txt.gz' does not need to be reloaded Tue Jan 19 18:55:54 2010 VENDOR: ntop continues ok Tue Jan 19 18:55:54 2010 VENDOR: Checking for MAC address table file Tue Jan 19 18:55:54 2010 VENDOR: File '/usr/local/etc/ntop/oui.txt.gz' does not need to be reloaded Tue Jan 19 18:55:54 2010 VENDOR: ntop continues ok Tue Jan 19 18:55:54 2010 Fingerprint: Loading signature file Tue Jan 19 18:55:54 2010 Fingerprint: Checking for Fingerprint file... file Tue Jan 19 18:55:54 2010 Fingerprint: Loading file '/usr/local/etc/ntop/etter.finger.os.gz' Tue Jan 19 18:55:54 2010 Fingerprint: ...loaded 0 records Tue Jan 19 18:55:54 2010 ASN: Checking for Autonomous System Number table file Tue Jan 19 18:55:54 2010 ASN: Loading file '/usr/local/etc/ntop/AS-list.txt.gz' Tue Jan 19 18:55:55 2010 ASN: ...found 111435 lines Tue Jan 19 18:55:55 2010 ASN: ....Used 3780 KB of memory (12 per entry) Tue Jan 19 18:55:55 2010 IP2CC: Checking for IP address <-> Country Code mapping file Tue Jan 19 18:55:55 2010 IP2CC: Loading file '/usr/local/etc/ntop/p2c.opt.table.gz' Tue Jan 19 18:55:56 2010 IP2CC: ...found 52395 lines Tue Jan 19 18:55:56 2010 Database support not compiled into ntop Tue Jan 19 18:55:56 2010 Initializing external applications Tue Jan 19 18:55:56 2010 THREADMGMT[t683675984]: SFP: Started thread for fingerprinting Tue Jan 19 18:55:56 2010 THREADMGMT[t683676256]: SIH: Started thread for idle hosts detection Tue Jan 19 18:55:56 2010 THREADMGMT[t683676528]: DNSAR(1): Started thread for DNS address resolution Tue Jan 19 18:55:56 2010 THREADMGMT[t683676800]: DNSAR(2): Started thread for DNS address resolution Tue Jan 19 18:55:56 2010 THREADMGMT[t683677072]: DNSAR(3): Started thread for DNS address resolution Tue Jan 19 18:55:56 2010 Calling plugin start functions (if any) Tue Jan 19 18:55:56 2010 SSL is present but https is disabled: use -W <https port="">for enabling it Tue Jan 19 18:55:56 2010 INITWEB: Initializing web server Tue Jan 19 18:55:56 2010 INITWEB: Initializing TCP/IP socket connections for web server Tue Jan 19 18:55:56 2010 INITWEB: Initialized socket, port 3000, address (any) Tue Jan 19 18:55:56 2010 INITWEB: Waiting for HTTP connections on port 3000 Tue Jan 19 18:55:56 2010 INITWEB: Starting web server Tue Jan 19 18:55:56 2010 THREADMGMT[t683677344]: INITWEB: Started thread for web server Tue Jan 19 18:55:56 2010 Listening on [fxp0,fxp1,fxp2] Tue Jan 19 18:55:56 2010 Loading Plugins Tue Jan 19 18:55:56 2010 Searching for plugins in /usr/local/lib/ntop/plugins Tue Jan 19 18:55:56 2010 CPACKET: Welcome to cPacket.(C) 2008 by Luca Deri Tue Jan 19 18:55:56 2010 ICMP: Welcome to ICMP Watch. (C) 1999-2005 by Luca Deri Tue Jan 19 18:55:56 2010 LASTSEEN: Welcome to Host Last Seen. (C) 1999 by Andrea Marangoni Tue Jan 19 18:55:56 2010 NETFLOW: Welcome to NetFlow.(C) 2002-08 by Luca Deri Tue Jan 19 18:55:56 2010 PDA: Welcome to PDA. (C) 2001-2005 by L.Deri and W.Brock Tue Jan 19 18:55:56 2010 Remote: Welcome to Remote. (C) 2006-07 by L.Deri Tue Jan 19 18:55:56 2010 RRD: Welcome to Round-Robin Databases. (C) 2002-07 by Luca Deri. Tue Jan 19 18:55:56 2010 SFLOW: Welcome to sFlow.(C) 2002-04 by Luca Deri Tue Jan 19 18:55:56 2010 Calling plugin start functions (if any) Tue Jan 19 18:55:56 2010 RRD: Welcome to the RRD plugin Tue Jan 19 18:55:56 2010 RRD: Mask for new directories is 0700 Tue Jan 19 18:55:56 2010 RRD: Mask for new files is 0066 Tue Jan 19 18:55:56 2010 RRD_DEBUG: Parameters: Tue Jan 19 18:55:56 2010 RRD_DEBUG: dumpInterval 300 seconds Tue Jan 19 18:55:56 2010 RRD_DEBUG: dumpShortInterval 10 seconds Tue Jan 19 18:55:56 2010 RRD_DEBUG: dumpHours 72 hours by 300 seconds Tue Jan 19 18:55:56 2010 RRD_DEBUG: dumpDays 90 days by hour Tue Jan 19 18:55:56 2010 RRD_DEBUG: dumpMonths 36 months by day Tue Jan 19 18:55:56 2010 RRD_DEBUG: dumpDomains no Tue Jan 19 18:55:56 2010 RRD_DEBUG: dumpFlows no Tue Jan 19 18:55:56 2010 RRD_DEBUG: dumpSubnets no Tue Jan 19 18:55:56 2010 RRD_DEBUG: dumpHosts no Tue Jan 19 18:55:56 2010 RRD_DEBUG: dumpInterfaces yes Tue Jan 19 18:55:56 2010 RRD_DEBUG: dumpASs no Tue Jan 19 18:55:56 2010 RRD_DEBUG: dumpMatrix no Tue Jan 19 18:55:56 2010 RRD_DEBUG: dumpDetail medium Tue Jan 19 18:55:56 2010 RRD_DEBUG: hostsFilter Tue Jan 19 18:55:56 2010 RRD_DEBUG: rrdPath /var/db/ntop/rrd [normal] Tue Jan 19 18:55:56 2010 RRD_DEBUG: rrdPath /var/db/ntop/rrd [dynamic/volatile] Tue Jan 19 18:55:56 2010 RRD_DEBUG: umask 0066 Tue Jan 19 18:55:56 2010 RRD_DEBUG: DirPerms 0700 Tue Jan 19 18:55:56 2010 THREADMGMT: RRD: Started thread (t683677616) for data collection Tue Jan 19 18:55:56 2010 INIT: Created pid file (/var/run/ntop.pid) Tue Jan 19 18:55:56 2010 THREADMGMT[t683675712]: ntop RUNSTATE: INITNONROOT(3) Tue Jan 19 18:55:56 2010 Now running as requested user 'nobody' (65534:65534) Tue Jan 19 18:55:56 2010 Note: Reporting device initally set to 0 [fxp0] (merged) Tue Jan 19 18:55:56 2010 THREADMGMT[t683675712]: ntop RUNSTATE: RUN(4) Tue Jan 19 18:55:56 2010 THREADMGMT[t683677888]: NPS(1): Started thread for network packet sniffing [fxp0] Tue Jan 19 18:55:56 2010 THREADMGMT[t683678160]: NPS(2): Started thread for network packet sniffing [fxp1] Tue Jan 19 18:55:56 2010 THREADMGMT[t683678432]: NPS(3): Started thread for network packet sniffing [fxp2] Tue Jan 19 18:55:56 2010 THREADMGMT[t683676528]: DNSAR(1): Address resolution thread running Tue Jan 19 18:55:56 2010 THREADMGMT[t683677072]: DNSAR(3): Address resolution thread running Tue Jan 19 18:55:56 2010 THREADMGMT[t683677616]: RRD: Data collection thread starting [p35233] Tue Jan 19 18:55:56 2010 THREADMGMT[t683678160]: NPS(fxp1): pcapDispatch thread starting [p35233] Tue Jan 19 18:55:56 2010 THREADMGMT[t683678160]: NPS(fxp1): pcapDispatch thread running [p35233] Tue Jan 19 18:55:56 2010 THREADMGMT[t683675984]: SFP: Fingerprint scan thread starting [p35233] Tue Jan 19 18:55:56 2010 THREADMGMT[t683675984]: SFP: Fingerprint scan thread running [p35233] Tue Jan 19 18:55:56 2010 THREADMGMT[t683676800]: DNSAR(2): Address resolution thread running Tue Jan 19 18:55:56 2010 THREADMGMT[t683677888]: NPS(fxp0): pcapDispatch thread starting [p35233] Tue Jan 19 18:55:56 2010 THREADMGMT[t683677888]: NPS(fxp0): pcapDispatch thread running [p35233] Tue Jan 19 18:55:56 2010 THREADMGMT[t683676256]: SIH: Idle host scan thread starting [p35233] Tue Jan 19 18:55:56 2010 THREADMGMT[t683676256]: SIH: Idle host scan thread running [p35233] Tue Jan 19 18:55:56 2010 THREADMGMT[t683678432]: NPS(fxp2): pcapDispatch thread starting [p35233] Tue Jan 19 18:55:56 2010 THREADMGMT[t683678432]: NPS(fxp2): pcapDispatch thread running [p35233] Tue Jan 19 18:55:56 2010 THREADMGMT[t683677344]: WEB: Server connection thread starting [p35233] Tue Jan 19 18:55:56 2010 Note: SIGPIPE handler set (ignore) Tue Jan 19 18:55:56 2010 THREADMGMT[t683677344]: WEB: Server connection thread running [p35233] Tue Jan 19 18:55:56 2010 WEB: ntop's web server is now processing requests Tue Jan 19 18:56:06 2010 THREADMGMT[t683678704]: RRD: Started thread for throughput data collection Tue Jan 19 18:56:06 2010 THREADMGMT[t683677616]: RRD: Data collection thread running [p35233] Tue Jan 19 18:56:06 2010 THREADMGMT[t683678704]: RRD: Throughput data collection: Thread starting [p35233] Tue Jan 19 18:56:06 2010 THREADMGMT[t683678704]: RRD: Throughput data collection: Thread running [p35233] Tue Jan 19 19:00:38 2010 CLEANUP[t683678704]: ntop caught signal 15 [state=4] Tue Jan 19 19:00:38 2010 THREADMGMT[t683678704]: ntop RUNSTATE: SHUTDOWN(7) Tue Jan 19 19:00:38 2010 CLEANUP[t683678704] catching thread is unknown Tue Jan 19 19:00:38 2010 CLEANUP: Running threads SFP SIH WEB DNSAR1 DNSAR2 DNSAR3 NPS(fxp0) NPS(fxp1) NPS(fxp2) Tue Jan 19 19:00:38 2010 Joining thread DNSAR1 Tue Jan 19 19:00:38 2010 THREADMGMT[t683676528]: DNSAR(1): Address resolution thread terminated [p35233] Tue Jan 19 19:00:38 2010 Joining thread DNSAR2 Tue Jan 19 19:00:38 2010 THREADMGMT[t683676800]: DNSAR(2): Address resolution thread terminated [p35233] Tue Jan 19 19:00:38 2010 Joining thread DNSAR3 Tue Jan 19 19:00:38 2010 THREADMGMT[t683677072]: DNSAR(3): Address resolution thread terminated [p35233] Tue Jan 19 19:00:38 2010 STATS: 6,738 packets received by filter on fxp0 Tue Jan 19 19:00:38 2010 STATS: 222 packets dropped (according to libpcap) Tue Jan 19 19:00:38 2010 STATS: 0 packets dropped (by ntop) Tue Jan 19 19:00:38 2010 Joining thread NPS(fxp0) Tue Jan 19 19:00:38 2010 THREADMGMT[t683678160]: NPS(fxp1): pcapDispatch thread terminated [p35233] Tue Jan 19 19:00:39 2010 THREADMGMT[t683678432]: NPS(fxp2): pcapDispatch thread terminated [p35233] Tue Jan 19 19:00:39 2010 THREADMGMT[t683677888]: NPS(fxp0): pcapDispatch thread terminated [p35233] Tue Jan 19 19:00:39 2010 CLEANUP: Locking purge mutex (may block for a little while) Tue Jan 19 19:00:39 2010 CLEANUP: Locked purge mutex, continuing shutdown Tue Jan 19 19:00:39 2010 CLEANUP: Continues (still running SFP SIH WEB) Tue Jan 19 19:00:39 2010 FREE_HOST: Start, 1 device(s) Tue Jan 19 19:00:39 2010 FREE_HOST: End, freed 0 Tue Jan 19 19:00:39 2010 FREE_HOST: Start, 1 device(s) Tue Jan 19 19:00:39 2010 FREE_HOST: End, freed 0 Tue Jan 19 19:00:39 2010 FREE_HOST: Start, 1 device(s) Tue Jan 19 19:00:39 2010 FREE_HOST: End, freed 0 Tue Jan 19 19:00:39 2010 PLUGIN_TERM: Unloading plugins (if any) Tue Jan 19 19:00:39 2010 RRD: Shutting down, locking mutex (may block for a little while) Tue Jan 19 19:00:39 2010 RRD: Locked mutex, continuing shutdown Tue Jan 19 19:00:39 2010 THREADMGMT[t683678704]: RRD: killThread(rrdThread) succeeded Tue Jan 19 19:00:39 2010 THREADMGMT[t683678704]: RRD: killThread(rrdTrafficThread) succeeded Tue Jan 19 19:00:39 2010 THREADMGMT[t683678704]: RRD: Plugin shutdown continuing Tue Jan 19 19:00:39 2010 RRD: Thanks for using the rrdPlugin Tue Jan 19 19:00:39 2010 RRD: Done Tue Jan 19 19:00:39 2010 CLEANUP: Freeing device fxp0 Tue Jan 19 19:00:39 2010 CLEANUP: Freeing device fxp1 Tue Jan 19 19:00:39 2010 CLEANUP: Freeing device fxp2 Tue Jan 19 19:00:39 2010 **WARNING** TERM: Unable to remove pid file (/var/run/ntop.pid) Tue Jan 19 19:00:39 2010 CLEANUP: Clean up complete Tue Jan 19 19:00:39 2010 THREADMGMT[t683678704]: ntop RUNSTATE: TERM(8) Tue Jan 19 19:00:39 2010 CLEANUP[t683678704]: Still running threads SFP SIH WEB Tue Jan 19 19:00:39 2010 =================================== Tue Jan 19 19:00:39 2010 ntop is shutdown... Tue Jan 19 19:00:39 2010 ===================================</https></deri@ntop.org>EDIT: Sometimes when I run ntop, I get this:
# ntop Tue Jan 19 19:17:15 2010 NOTE: Interface merge enabled by default Tue Jan 19 19:17:15 2010 Initializing gdbm databases Tue Jan 19 19:17:15 2010 ntop will be started as user nobody Tue Jan 19 19:17:15 2010 ntop v.3.3.8 Tue Jan 19 19:17:15 2010 Configured on Dec 4 2008 15:19:28, built on Dec 4 2008 15:19:59. Tue Jan 19 19:17:15 2010 Copyright 1998-2007 by Luca Deri <deri@ntop.org>Tue Jan 19 19:17:15 2010 Get the freshest ntop from http://www.ntop.org/ Tue Jan 19 19:17:15 2010 NOTE: ntop is running from 'ntop' Tue Jan 19 19:17:15 2010 NOTE: (but see warning on man page for the --instance parameter) Tue Jan 19 19:17:15 2010 NOTE: ntop libraries are in '/usr/local/lib' Tue Jan 19 19:17:15 2010 Initializing ntop Tue Jan 19 19:17:15 2010 No patterns to load: protocol guessing disabled. Tue Jan 19 19:17:15 2010 Checking fxp0 for additional devices Tue Jan 19 19:17:15 2010 Resetting traffic statistics for device fxp0 Tue Jan 19 19:17:15 2010 Initializing device fxp0 (0) Tue Jan 19 19:17:15 2010 DLT: Device 0 [fxp0] is 1, mtu 1514, header 14 Tue Jan 19 19:17:15 2010 Checking fxp1 for additional devices Tue Jan 19 19:17:15 2010 Resetting traffic statistics for device fxp1 Tue Jan 19 19:17:15 2010 Initializing device fxp1 (1) Tue Jan 19 19:17:15 2010 DLT: Device 1 [fxp1] is 1, mtu 1514, header 14 Tue Jan 19 19:17:15 2010 Checking fxp2 for additional devices Tue Jan 19 19:17:15 2010 Resetting traffic statistics for device fxp2 Tue Jan 19 19:17:15 2010 Initializing device fxp2 (2) Tue Jan 19 19:17:15 2010 DLT: Device 2 [fxp2] is 1, mtu 1514, header 14 Tue Jan 19 19:17:15 2010 Initializing gdbm databases Tue Jan 19 19:17:15 2010 VENDOR: Loading MAC address table. Tue Jan 19 19:17:15 2010 VENDOR: Checking for MAC address table file Tue Jan 19 19:17:15 2010 VENDOR: File '/usr/local/etc/ntop/specialMAC.txt.gz' does not need to be reloaded Tue Jan 19 19:17:15 2010 VENDOR: ntop continues ok Tue Jan 19 19:17:15 2010 VENDOR: Checking for MAC address table file Tue Jan 19 19:17:15 2010 VENDOR: File '/usr/local/etc/ntop/oui.txt.gz' does not need to be reloaded Tue Jan 19 19:17:15 2010 VENDOR: ntop continues ok Tue Jan 19 19:17:15 2010 Fingerprint: Loading signature file Tue Jan 19 19:17:15 2010 Fingerprint: Checking for Fingerprint file... file Tue Jan 19 19:17:15 2010 Fingerprint: Loading file '/usr/local/etc/ntop/etter.finger.os.gz' Tue Jan 19 19:17:15 2010 Fingerprint: ...loaded 0 records Tue Jan 19 19:17:15 2010 ASN: Checking for Autonomous System Number table file Tue Jan 19 19:17:15 2010 ASN: Loading file '/usr/local/etc/ntop/AS-list.txt.gz' Tue Jan 19 19:17:17 2010 ASN: ...found 111435 lines Tue Jan 19 19:17:17 2010 ASN: ....Used 3780 KB of memory (12 per entry) Tue Jan 19 19:17:17 2010 IP2CC: Checking for IP address <-> Country Code mapping file Tue Jan 19 19:17:17 2010 IP2CC: Loading file '/usr/local/etc/ntop/p2c.opt.table.gz' Tue Jan 19 19:17:17 2010 IP2CC: ...found 52395 lines Tue Jan 19 19:17:17 2010 Database support not compiled into ntop Tue Jan 19 19:17:17 2010 Initializing external applications Tue Jan 19 19:17:17 2010 THREADMGMT[t683675984]: SFP: Started thread for fingerprinting Tue Jan 19 19:17:17 2010 THREADMGMT[t683676256]: SIH: Started thread for idle hosts detection Tue Jan 19 19:17:17 2010 THREADMGMT[t683676528]: DNSAR(1): Started thread for DNS address resolution Tue Jan 19 19:17:17 2010 THREADMGMT[t683676800]: DNSAR(2): Started thread for DNS address resolution Tue Jan 19 19:17:17 2010 THREADMGMT[t683677072]: DNSAR(3): Started thread for DNS address resolution Tue Jan 19 19:17:17 2010 Calling plugin start functions (if any) Tue Jan 19 19:17:17 2010 SSL is present but https is disabled: use -W <https port="">for enabling it Tue Jan 19 19:17:17 2010 INITWEB: Initializing web server Tue Jan 19 19:17:17 2010 INITWEB: Initializing TCP/IP socket connections for web server Tue Jan 19 19:17:17 2010 INITWEB: Initialized socket, port 3000, address (any) Tue Jan 19 19:17:17 2010 INITWEB: Waiting for HTTP connections on port 3000 Tue Jan 19 19:17:17 2010 INITWEB: Starting web server Tue Jan 19 19:17:17 2010 THREADMGMT[t683677344]: INITWEB: Started thread for web server Tue Jan 19 19:17:17 2010 Listening on [fxp0,fxp1,fxp2] Tue Jan 19 19:17:17 2010 Loading Plugins Tue Jan 19 19:17:17 2010 Searching for plugins in /usr/local/lib/ntop/plugins Tue Jan 19 19:17:17 2010 CPACKET: Welcome to cPacket.(C) 2008 by Luca Deri Tue Jan 19 19:17:17 2010 ICMP: Welcome to ICMP Watch. (C) 1999-2005 by Luca Deri Tue Jan 19 19:17:17 2010 LASTSEEN: Welcome to Host Last Seen. (C) 1999 by Andrea Marangoni Tue Jan 19 19:17:17 2010 NETFLOW: Welcome to NetFlow.(C) 2002-08 by Luca Deri Tue Jan 19 19:17:17 2010 PDA: Welcome to PDA. (C) 2001-2005 by L.Deri and W.Brock Tue Jan 19 19:17:17 2010 Remote: Welcome to Remote. (C) 2006-07 by L.Deri Tue Jan 19 19:17:17 2010 RRD: Welcome to Round-Robin Databases. (C) 2002-07 by Luca Deri. Tue Jan 19 19:17:17 2010 SFLOW: Welcome to sFlow.(C) 2002-04 by Luca Deri Tue Jan 19 19:17:17 2010 Calling plugin start functions (if any) Tue Jan 19 19:17:17 2010 RRD: Welcome to the RRD plugin Tue Jan 19 19:17:17 2010 RRD: Mask for new directories is 0700 Tue Jan 19 19:17:17 2010 RRD: Mask for new files is 0066 Tue Jan 19 19:17:17 2010 RRD_DEBUG: Parameters: Tue Jan 19 19:17:17 2010 RRD_DEBUG: dumpInterval 300 seconds Tue Jan 19 19:17:17 2010 RRD_DEBUG: dumpShortInterval 10 seconds Tue Jan 19 19:17:17 2010 RRD_DEBUG: dumpHours 72 hours by 300 seconds Tue Jan 19 19:17:17 2010 RRD_DEBUG: dumpDays 90 days by hour Tue Jan 19 19:17:17 2010 RRD_DEBUG: dumpMonths 36 months by day Tue Jan 19 19:17:17 2010 RRD_DEBUG: dumpDomains no Tue Jan 19 19:17:17 2010 RRD_DEBUG: dumpFlows no Tue Jan 19 19:17:17 2010 RRD_DEBUG: dumpSubnets no Tue Jan 19 19:17:17 2010 RRD_DEBUG: dumpHosts no Tue Jan 19 19:17:17 2010 RRD_DEBUG: dumpInterfaces yes Tue Jan 19 19:17:17 2010 RRD_DEBUG: dumpASs no Tue Jan 19 19:17:17 2010 RRD_DEBUG: dumpMatrix no Tue Jan 19 19:17:17 2010 RRD_DEBUG: dumpDetail medium Tue Jan 19 19:17:17 2010 RRD_DEBUG: hostsFilter Tue Jan 19 19:17:17 2010 RRD_DEBUG: rrdPath /var/db/ntop/rrd [normal] Tue Jan 19 19:17:17 2010 RRD_DEBUG: rrdPath /var/db/ntop/rrd [dynamic/volatile] Tue Jan 19 19:17:17 2010 RRD_DEBUG: umask 0066 Tue Jan 19 19:17:17 2010 RRD_DEBUG: DirPerms 0700 Tue Jan 19 19:17:17 2010 THREADMGMT: RRD: Started thread (t683677616) for data collection Tue Jan 19 19:17:17 2010 INIT: Created pid file (/var/run/ntop.pid) Tue Jan 19 19:17:17 2010 THREADMGMT[t683675712]: ntop RUNSTATE: INITNONROOT(3) Tue Jan 19 19:17:17 2010 Now running as requested user 'nobody' (65534:65534) Tue Jan 19 19:17:17 2010 Note: Reporting device initally set to 0 [fxp0] (merged) Tue Jan 19 19:17:17 2010 THREADMGMT[t683675712]: ntop RUNSTATE: RUN(4) Tue Jan 19 19:17:17 2010 THREADMGMT[t683677888]: NPS(1): Started thread for network packet sniffing [fxp0] Tue Jan 19 19:17:17 2010 THREADMGMT[t683678160]: NPS(2): Started thread for network packet sniffing [fxp1] Tue Jan 19 19:17:17 2010 THREADMGMT[t683678432]: NPS(3): Started thread for network packet sniffing [fxp2] Tue Jan 19 19:17:17 2010 THREADMGMT[t683677344]: WEB: Server connection thread starting [p38354] Tue Jan 19 19:17:17 2010 Note: SIGPIPE handler set (ignore) Tue Jan 19 19:17:17 2010 THREADMGMT[t683677344]: WEB: Server connection thread running [p38354] Tue Jan 19 19:17:17 2010 WEB: ntop's web server is now processing requests Tue Jan 19 19:17:17 2010 THREADMGMT[t683678432]: NPS(fxp2): pcapDispatch thread starting [p38354] Tue Jan 19 19:17:17 2010 THREADMGMT[t683678432]: NPS(fxp2): pcapDispatch thread running [p38354] Tue Jan 19 19:17:17 2010 THREADMGMT[t683677888]: NPS(fxp0): pcapDispatch thread starting [p38354] Tue Jan 19 19:17:17 2010 THREADMGMT[t683677888]: NPS(fxp0): pcapDispatch thread running [p38354] Tue Jan 19 19:17:17 2010 THREADMGMT[t683676800]: DNSAR(2): Address resolution thread running Tue Jan 19 19:17:17 2010 THREADMGMT[t683675984]: SFP: Fingerprint scan thread starting [p38354] Tue Jan 19 19:17:17 2010 THREADMGMT[t683675984]: SFP: Fingerprint scan thread running [p38354] Tue Jan 19 19:17:17 2010 THREADMGMT[t683678160]: NPS(fxp1): pcapDispatch thread starting [p38354] Tue Jan 19 19:17:17 2010 THREADMGMT[t683678160]: NPS(fxp1): pcapDispatch thread running [p38354] Tue Jan 19 19:17:17 2010 THREADMGMT[t683676256]: SIH: Idle host scan thread starting [p38354] Tue Jan 19 19:17:17 2010 THREADMGMT[t683676256]: SIH: Idle host scan thread running [p38354] Tue Jan 19 19:17:17 2010 THREADMGMT[t683676528]: DNSAR(1): Address resolution thread running Tue Jan 19 19:17:17 2010 THREADMGMT[t683677616]: RRD: Data collection thread starting [p38354] Tue Jan 19 19:17:17 2010 THREADMGMT[t683677072]: DNSAR(3): Address resolution thread running Tue Jan 19 19:17:27 2010 THREADMGMT[t683678704]: RRD: Started thread for throughput data collection Tue Jan 19 19:17:27 2010 THREADMGMT[t683677616]: RRD: Data collection thread running [p38354] Tue Jan 19 19:17:27 2010 THREADMGMT[t683678704]: RRD: Throughput data collection: Thread starting [p38354] Tue Jan 19 19:17:27 2010 THREADMGMT[t683678704]: RRD: Throughput data collection: Thread running [p38354] Segmentation fault</https></deri@ntop.org>I wonder what the segmentation fault means. At any rate, I'm starting to think that maybe this is a problem for the ntop forums.
EDIT:
When it does crash, this is what I get in the system logs:
Jan 19 19:40:41 kernel: pid 44607 (ntop), uid 65534: exited on signal 11 Jan 19 19:40:41 kernel: fxp2: promiscuous mode disabled Jan 19 19:42:02 ntop[45485]: THREADMGMT[t683675712]: ntop RUNSTATE: PREINIT(1) Jan 19 19:42:02 ntop[45485]: THREADMGMT[t683675712]: ntop RUNSTATE: INIT(2) Jan 19 19:42:19 ntop[45586]: THREADMGMT[t683675712]: ntop RUNSTATE: PREINIT(1) Jan 19 19:42:19 ntop[45586]: THREADMGMT[t683675712]: ntop RUNSTATE: INIT(2)The ntop runstate is when I manually start it again.
Anyhow, I've started ntop as root and so far its not crashed. We will see… it might just be permission and ownership problems.
-
My suggestion, install the "monit" package and have it monitor your ntop process. Monit will automatically restart ntop if/when it dies again. Plus, you get automatic notification when an event occurs. Just do a search for "monit" in the package forum.
Let me know if you need any help.
-
My suggestion, install the "monit" package and have it monitor your ntop process. Monit will automatically restart ntop if/when it dies again. Plus, you get automatic notification when an event occurs. Just do a search for "monit" in the package forum.
Let me know if you need any help.
Does ntop still give accurate information even though it has to be restarted every 4-10 minutes?
-
Sorry, don't know enough about ntop to comment. Maybe someone else does?
-
Well, it looks to me like I've fixed it. Its been running for almost 20 minutes now with no problems. Usually it quits after 3 minutes. Sometimes even 30 secs.
It appears that it was a simple permission and ownership problem.
I just had to do
#chmod -R 755 /var/db/ntop #chown -R nobody:nobody /var/db/ntopSo now its working. I'm going to leave it be for a while and see if it continues to work. I do have one question though. I'm able to start it manually but it does not start when I hit the start service button in the gui. And I'm assuming that it will not start automatically at bootup. I've not tried that yet.
So, is there any way I can get it to start automatically? Also, does this "monit" package give pfsense a command like say, "ntop" so that it will start ntop? Because if not, then as things are right now… it won't work.
-
To automatically start the app on boot, edit the /usr/local/etc/rc.d/ntop.sh script and make sure the ENABLE option is set to "Y". Then, either reboot or run the script "/usr/local/etc/rc.d/ntop.sh start".
Once you get monit installed and running, add a section for ntop (look at the config file for examples). Here is what I use for "bandwidthd":
–-------------------------------------------------------------------
check process bandwidthd with pidfile /var/run/bandwidthd.pid
start program = "/usr/local/etc/rc.d/bandwidthd.sh start" with timeout 60 seconds
stop program = "/usr/local/etc/rc.d/bandwidthd.sh stop"
if 3 restarts within 5 cycles then timeout
group bandwidthdAlso, make sure you have the monit.sh script in /usr/local/etc and it has been ENABLED as well. This will make sure monit gets started when your box reboots.
-
It appears that it was a simple permission and ownership problem.
I just had to do
#chmod -R 755 /var/db/ntop #chown -R nobody:nobody /var/db/ntopThis worked for me as well. I have just fixed our ntop which was not working for a month or so after upgrading to 1.2.3. It also starts and stops from the gui now so i would assume that its completely fixed.
Thanks!
-
I committed a fix for the permissions to the ntop package just now, but I didn't do a version bump yet. If it turns out to work for everyone, I may do that just to signal to people there has been a change.
There were commands in there before that should have fixed the permissions, but the command wasn't specified with the full path so it may have been failing. I'd be curious if anyone who is experiencing the crashes would try to reinstall the ntop now (or rather about 5 minutes from the time of this post to be sure the commit is live on the package server).
I have one server I will be trying this one, where ntop would die quite often.
-
Thanks Jim. I may give ntop a try tonight and report back…
-
So far so good on mine. I upgraded just after I put the fix in and it's still running an hour and a half later (give or take), whereas before it would run at most about 10 minutes.
-
I'm running pfSense 1.2.3-RELEASE with 2 WAN/1 LAN setup and the latest ntop package from the package section and I'm still having problems with the ntop package.
FreeBSD pfsense.smartfox.us 7.2-RELEASE-p5 FreeBSD 7.2-RELEASE-p5 #0: Sun Dec 6
22:57:48 EST 2009 sullrich@FreeBSD_7.2_pfSense_1.2.3_snaps.pfsense.org:/usr
/obj.pfSense/usr/pfSensesrc/src/sys/pfSense.7 i386before, when it just core dump and that was it. Now, when it core dumps after I did the chmod/chown commands from a previous post, I get my system log spammed with these messages:
Feb 2 11:55:53 kernel: rl2: promiscuous mode enabled
Feb 2 11:55:53 kernel: rl2: promiscuous mode disabled
Feb 2 11:55:57 kernel: rl2: promiscuous mode enabled
Feb 2 11:55:58 kernel: rl2: promiscuous mode disabled
Feb 2 11:56:02 kernel: rl2: promiscuous mode enabled
Feb 2 11:56:02 kernel: rl2: promiscuous mode disabled
Feb 2 11:56:06 kernel: rl2: promiscuous mode enabled
Feb 2 11:56:07 kernel: rl2: promiscuous mode disabled
Feb 2 11:56:11 kernel: rl2: promiscuous mode enabled
Feb 2 11:56:11 kernel: rl2: promiscuous mode disabled
Feb 2 11:56:15 kernel: rl2: promiscuous mode enabled
Feb 2 11:56:15 kernel: rl2: promiscuous mode disabled
Feb 2 11:56:20 kernel: rl2: promiscuous mode enabled
Feb 2 11:56:20 kernel: rl2: promiscuous mode disabled
etc etc etcIt just seems to die after 4-5 min after it gets to the end of starting up when it just says collecting data. rl2 is my LAN interface.
I also have darkstat and bandwidthd installed. Would either of these be interferring with ntop? I have an old box running out on a customer's site running both (although i think they're running a 1.2 snapshot) no problem. If there's more data that I need to provide, let me know, please.
Thanks
EDIT I kinda hurried with the original post because we were going to eat lunch. Once I got back, I decided to try and run ntop from the command prompt. I ran ntop and everything seemed to be going fine. I waited about 10 min, had no problems and so I stopped the process. I saw it wasn't able to remove the pid file so I changed the ownership and permissions on the file and decided to try running it from the web GUI. Everything was running fine for a while and then:
Feb 2 13:58:48 ntop[51520]: THREADMGMT[t683678160]: RRD: Started thread for throughput data collection
Feb 2 13:58:48 ntop[51520]: THREADMGMT[t683678160]: RRD: Started thread for throughput data collection
Feb 2 13:58:48 ntop[51520]: THREADMGMT[t683677616]: RRD: Data collection thread running [p51520]
Feb 2 13:58:48 ntop[51520]: THREADMGMT[t683677616]: RRD: Data collection thread running [p51520]
Feb 2 13:58:48 ntop[51520]: THREADMGMT[t683678160]: RRD: Throughput data collection: Thread starting [p51520]
Feb 2 13:58:48 ntop[51520]: THREADMGMT[t683678160]: RRD: Throughput data collection: Thread starting [p51520]
Feb 2 13:58:48 ntop[51520]: THREADMGMT[t683678160]: RRD: Throughput data collection: Thread running [p51520]
Feb 2 13:58:48 ntop[51520]: THREADMGMT[t683678160]: RRD: Throughput data collection: Thread running [p51520]
Feb 2 13:58:55 check_reload_status: reloading filter
Feb 2 14:17:58 kernel: pid 51520 (ntop), uid 0: exited on signal 11 (core dumped)
Feb 2 14:21:12 dnsmasq[35614]: reading /var/dhcpd/var/db/dhcpd.leasesThat dnsmasq entry always seems to happen right after ntop core dumps. Nothing had changed. I was just F5ing the system log to see if it was still running. The only thing I guess I did differently was I didn't try accessing ntop while it was running to see if it'd atleast gather data for a while.
I'm gonna run it via the command prompt again and let it run for a while to see if I can find something more out. I was just interested if someone ran into this before and knew how to fix it.
EDIT II Alright, here's running ntop from the command prompt. I copy and pasted out of the web gui for timestamps but the terminal has the same thing minus the time:
Feb 2 14:39:58 ntop[56774]: THREADMGMT[t683677616]: RRD: Data collection thread running [p56774]
Feb 2 14:39:58 ntop[56774]: THREADMGMT[t683677616]: RRD: Data collection thread running [p56774]
Feb 2 14:39:58 ntop[56774]: THREADMGMT[t683678432]: RRD: Throughput data collection: Thread starting [p56774]
Feb 2 14:39:58 ntop[56774]: THREADMGMT[t683678432]: RRD: Throughput data collection: Thread starting [p56774]
Feb 2 14:39:58 ntop[56774]: THREADMGMT[t683678432]: RRD: Throughput data collection: Thread running [p56774]
Feb 2 14:39:58 ntop[56774]: THREADMGMT[t683678432]: RRD: Throughput data collection: Thread running [p56774]
Feb 2 14:40:21 ntop[56873]: THREADMGMT[t683675712]: ntop RUNSTATE: PREINIT(1)
Feb 2 14:40:21 ntop[56873]: THREADMGMT[t683675712]: ntop RUNSTATE: INIT(2)
Feb 2 14:46:52 kernel: pid 56873 (ntop), uid 0: exited on signal 11 (core dumped)
Feb 2 14:47:28 dnsmasq[35614]: reading /var/dhcpd/var/db/dhcpd.leasesI started the process with the same command-line option found in /usr/local/etc/rc.d/ntop.sh minus the -d so I could see what was going on. I didn't try accessing the web gui or anything while it was running so it was just gathering data. Is anyone else running bandwidthd and having the same issue? Am I gonna be left with having cron or monit restart the program every 5-10 minutes? What am I doing wrong? ???
-
Did you uninstall/reinstall the package after the date on my last post?
Also, those promisc. mode messages are typically seen with the rate package, not ntop. Do you have that installed?
The dnsmasq process happens periodically, and that one happened several minutes after your ntop crash, it's not related.
-
sorry, I didn't see your reply before I made my last edit.
Yes, I have rate installed. Should I try uninstalling it? and I installed ntop today for the first time (Feb 2, 2010).
Also, was old accounts wiped or something? I had an account I thought that was under this username from like 2007 or so and I had to recreate this account a while back to post.
-
The presence of the rate package shouldn't help or hurt ntop.
FYI- ntop is still running on my router at work since my post saying it was OK, and it used to only last 10 minutes and behave exactly like yours (core dump and all).
Old accounts shouldn't be wiped, but I can look one up by username or e-mail if you want me to check on one. Send me a PM if you want me to check.
-
Yeah, I tried removing the rate package and it didn't make a bit of difference. I actually deleted the ntop package after I made that post and reinstalled and got the same results. I had to leave work early for a doctor's appointment and had a fellow technician check it out for me. :-[
Anyways, I'm gonna try a few other things throughout the day and see if I can figure out what's going on. I've been pretty loyal to pfSense since I found the project and since I got hired back to this company after one of the owners departed, I've wanted to move from Endian back to pfSense. The only reason we used Endian was for the web interface it has for OpenVPN. Is the client tls/auth package pretty much the same thing?
As a side note, from what I've read, I can't wait to have the openvpn client export package working for 2.0. I woulda really liked to have used pfSense 2.0-BETA instead of 1.2.3-RELEASE but we ran into the issue where putting the IP in staticly made it where the box wouldn't keep the default route (atleast that's what the other tech said he ran into and said after checking google that he found it was a known issue).
If I figure out what my problem is, I'll be sure to report back to the forum as it's been invaluable for me in the past. :)
-
I removed all the network monitoring packages, rebooted the router and reinstalled ntop and now it works. Go figure.
Sorry :-[
-
I found a problem,the logs:
ERROR: sanity check failed < low memory >
what can I do I just knew how to use it
please teach me I am a chinese
-
Well, it looks to me like I've fixed it. Its been running for almost 20 minutes now with no problems. Usually it quits after 3 minutes. Sometimes even 30 secs.
It appears that it was a simple permission and ownership problem.
I just had to do
#chmod -R 755 /var/db/ntop #chown -R nobody:nobody /var/db/ntopThanks, this worked for me as well.
ntop was not working for some weeks, and now i can also starts and stops from the gui -
Seems to be working for me too But I had to uninstall darkstat to keep Ntop from crashing.
-
Hi all,
I'm new to pfSense and it's my first post ;)
I installed a pfSense (1.2.3) for my company using a multiwan connection and I have the same problem. Ntop die quickly. I tried to remove "bandwidthd" and reinstall ntop package, but it doesn't work.
I try the chmod/chown method, but it doesn't work neither.
But, perhaps I found something, in the webgui, when you start ntop, you can select the interface to scan. If I select the 3 (2 wan, 1 lan), there's the problem, ntop die. But when I select only the 2 wan, or when I select only the lan, it seems that ntop doesn't crash (usually ntop crash before 10 minutes, with that configuration ntop doesn't crash in one hour).
So, If someone have an idea to solve that in another way …
Cheers.
Gilles.
