Ooops. My bad. You're right, there was a backgrounded process running on the same machine. Back to the drawing board.
/EJS -----Original Message----- From: [EMAIL PROTECTED] [mailto:tnelson@;starpoint.com] Sent: Thursday, October 24, 2002 12:40 PM To: [EMAIL PROTECTED] Subject: RE: [Ntop] command vs. daemon mode When I've seen that error, it's generally meant one of two things: 1) user sysadmin doesn't have permission to write to /usr/local/var/ntop/ prefsCache.db 2) there is another instance of ntop running that has the prefsCache.db locked Hope that helps Tony Tony Nelson Director of IT Operations Starpoint Solutions 115 Broadway, 20th Fl. New York, NY 10006 "Stieglitz, Eric J. (DCSA)" To: "'Burton M. Strauss III'" <[EMAIL PROTECTED]>, Ntop <EStieglitz@excha <[EMAIL PROTECTED]> nge.ml.com> cc: Sent by: Subject: RE: [Ntop] command vs. daemon mode ntop-admin@unipi. it 10/24/2002 12:32 PM Please respond to ntop Burton, Here's a bit of truss output from a session that I just ran with the command `truss -fal ntop -u sysadmin > /var/tmp/ntop.out 2>&1 &` . Note that when I run the same `ntop -u sysadmin` **WITHOUT** backgrounding the process, the software does not crash. Here's the end of the truss from the backgrounded version. Why is the software unlinking the addressCache instead of reading it first (which it never attempts)? Any idea why it fails the write on the prefsCache? 1344/1: unlink("/usr/local/var/ntop/addressCache.db") = 0 1344/1: open("/usr/local/var/ntop/addressCache.db", O_RDWR|O_CREAT, 0664 ) = 3 1344/1: fstat(3, 0xFFBEF9B0) = 0 1344/1: fcntl(3, F_SETLK, 0xFFBEF988) = 0 1344/1: brk(0x001FF678) = 0 1344/1: brk(0x00201678) = 0 1344/1: brk(0x00201678) = 0 1344/1: brk(0x00203678) = 0 1344/1: brk(0x00203678) = 0 1344/1: brk(0x00207678) = 0 1344/1: write(3, "13 W9ACE\0\0 \0\0\0 \0".., 8192) = 8192 1344/1: write(3, "\0\0 @\0\0\0 @\0\0\0 @\0".., 8192) = 8192 1344/1: write(3, "\0\0\001\0\0 \0\0\0 `\0".., 8192) = 8192 1344/1: fdsync(3, O_RDONLY|O_SYNC) = 0 1344/1: open("/usr/local/var/ntop/prefsCache.db", O_RDWR|O_CREAT, 0664) = 4 1344/1: fstat(4, 0xFFBEF9B0) = 0 1344/1: fcntl(4, F_SETLK, 0xFFBEF988) Err#11 EAGAIN 1344/1: close(4) = 0 1344/1: time() = 1035476629 24/Oct/2002 12:23:49 Database '/usr/local/var/ntop/prefsCache.db' open failed: C an't be writer 1344/1: write(1, " 2 4 / O c t / 2 0 0 2 ".., 95) = 95 1344/1: llseek(0, 0, SEEK_CUR) = 373509 1344/1: _exit(-1) /EJS -----Original Message----- From: Burton M. Strauss III [mailto:Burton@;ntopsupport.com] Sent: Wednesday, October 23, 2002 4:12 PM To: Ntop Cc: Johnston, Christopher (DCSA); Stieglitz, Eric J. (DCSA) Subject: RE: [Ntop] command vs. daemon mode No... run grep on the source - you'll find where the database names are set and the fields that make them up. But I still think it's a gdbm problem. Have you tried DELETING all of the .db files and recreating the password... -----Burton -----Original Message----- From: Stieglitz, Eric J. (DCSA) [mailto:EStieglitz@;exchange.ml.com] Sent: Wednesday, October 23, 2002 1:45 PM To: 'Burton M. Strauss III'; Ntop Cc: Johnston, Christopher (DCSA) Subject: RE: [Ntop] command vs. daemon mode I want to make sure I understand -- you want me to run a `strings -a` on the ntop binary and grep for '\.db' ? I'll need to check the allocated size thing by checking Solaris 8 specs... GDBM is an interesting idea. I'll have to look at that. /EJS -----Original Message----- From: Burton M. Strauss III [mailto:Burton@;ntopsupport.com] Sent: Wednesday, October 23, 2002 1:59 PM To: Ntop Cc: Stieglitz, Eric J. (DCSA) Subject: RE: [Ntop] command vs. daemon mode grep for '\.db' -- you'll see the snprintf()s that make the char[] value for the open()s. I think you're right about where it's writing to... What strikes me as odd is the uniform size, unless Solaris is showing allocated size? 11:37:45 tigger [Linux] user=bstrauss pwd=/shared/work/linux/ntop $ ls /usr/share/ntop -l *.db total 7344 -rw-r--r-- 1 root root 12361 Oct 23 12:02 addressCache.db -rw-r--r-- 1 root root 18931 Oct 23 12:09 dnsCache.db -rw-r--r-- 1 root root 7407857 Oct 23 12:09 hostsInfo.db -rw-rw-r-- 1 root root 12859 Oct 23 12:09 LsWatch.db -rw-r--r-- 1 root root 12437 Oct 12 17:17 ntop_pw.db -rw-r--r-- 1 root root 12775 Oct 23 10:47 prefsCache.db It's GOT to be some kind of permissions problem, but I'm completely clueless as to what. - Check out this article - http://www.systemtoolbox.com/article.php?articles_id=109 - there seem to be some Solaris tools you can use to query and write to gdbm databases.. - Have you asked on the gdbm list? -----Burton -----Original Message----- From: Stieglitz, Eric J. (DCSA) [mailto:EStieglitz@;exchange.ml.com] Sent: Wednesday, October 23, 2002 12:00 PM To: 'Burton M. Strauss III'; [EMAIL PROTECTED] Subject: RE: [Ntop] command vs. daemon mode Burton, How does one figure out where ntop is trying to write its .db files? I'm pretty sure that these are going in /usr/local/var/ntop: # ls -al /usr/local/var/ntop total 292 drwxrwxrwx 2 root root 512 Oct 23 12:55 . drwxr-xr-x 3 root root 512 Oct 23 12:43 .. -rwxrwxrwx 1 root root 24576 Oct 23 12:43 LsWatch.db -rw-r--r-- 1 root root 24576 Oct 23 12:55 addressCache.db -rwxrwxrwx 1 root root 24576 Oct 23 12:43 dnsCache.db -rwxrwxrwx 1 root root 24576 Oct 23 12:43 hostsInfo.db -rwxrwxrwx 1 root root 24576 Oct 23 12:43 ntop_pw.db -rwxrwxrwx 1 root root 24576 Oct 23 12:43 prefsCache.db Now, here's something interesting....I did a chmod a+rwx on this directory to see if that affected anything. When I restarted ntop with `ntop -u sysadmin`, obviously addressCache.db was recreated because its permissions are not the same as the other files! Any idea as to what could be causing this? _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop
