(see below)
-----Original Message-----
That would be great :) The FreeBSD port is sponsored by the University of Tromsø (and I think maybe the University of Bergen, both of which are FreeBSD proponents), but I'm not exactly sure who maintains the port (not being a FreeBSD guy myself). It's a shame no-one has contacted us if there is a build problem with the port.
I'll go ahead and start the compile on 7.x and I can email you the output so that you can see what's happening (along with version, etc)
I started looking through some of our cron catches and found the following errors (numerous instances of each):
cricket/collect-subtrees normal: Could not read /usr/local/cricket/subtree-sets file
Does that file exist at all, or is it just that the permissions are wrong?
It exists as: /usr/local/cricket/cricket-1.0.5/subtree-sets
Again - Cricket was installed via the standard ports collection. I believe that I have this resolved as well.
Hm, which version of NAV is in the FreeBSD port? If your Java VM supports the java.ext.dirs option, you shouldn't need to set such a big classpath. The getBoksMacs.sh script will set the option '-Djava.ext.dir=/usr/local/nav/lib/java' when calling the java executable, which will make sure all the jar files from /usr/local/nav/lib/java/ will be loaded.
NAV v3.2.2
Unfortunately, I know just enough to be 'dangerous' with java. I've added the symlinks and updated tomcat appropriately. Tried restart everything - same errors.
Try executing the alertengine init script directly (as root) and see if any errors crop up in the terminal:
/usr/local/nav/etc/init.d/alertengine start
There appeared to be a couple errors that I fixed (minor permission issues). However, now upon starting alertengine it just appears to just stall (see notes below).
You didn't mention what you found in getDeviceData-stderr.log and eventEngine-stderr.log?
Those files weren't being created. Now they are. ;-)
It appears now that I can start each of the services (located in init.d) by hand, but not via 'nav start' or 'nav start (service)'.
It appears that when doing a 'truss' on the execution of the program there are tons of 'ERR' lines - appears that some files aren't found and others just take numerous attempts at various locations to find. Now that all the services are running (pping took about 6 times of 'nav start pping' and now it's running as well). Here are the last few lines while running truss (truss -f -a -s 64 nav stop alertengine) against 'nav stop alertengine':
49669: close(3) = 0 (0x0) 49669: setpriority(0x0,0x0,0x0) = 0 (0x0) 49669: chdir("/usr/local/nav") = 0 (0x0)
Without looking at forked processes:
geteuid() = 0 (0x0) sigaction(SIGINT,{ SIG_IGN SA_SIGINFO ss_t },0x0) = 0 (0x0) sigaction(SIGQUIT,{ SIG_IGN SA_SIGINFO ss_t },0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGCHLD,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,SIGCHLD) = 0 (0x0) sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,SIGCHLD) = 0 (0x0) fork() = 52919 (0xceb7) sigprocmask(SIG_SETMASK,SIGCHLD,0x0) = 0 (0x0)
--- Notably, the lines previous to the above are open("/usr/local/nav/etc/cron.d/(various files)"), followed by an fstat and then a read. When it hits this point, the process and any associated forks appears to stall. I let the process run for a couple minutes just to see if perhaps it was waiting for a return from another process (perhaps communication with another process?)