On Fri, 2 May 2008 15:21:50 -0400 "Scorpion7" scorpion7@iqonline.net wrote:
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.
Yet, if cricket says it can't read /usr/local/cricket/subtree-sets, then it either doesn't exist, or the permissions are wrong. Does the port setup run the cricket collector as the cricket user, or the navcron user?
also, don't forget that NAV comes with a copy of the subtree-sets config file that is proper for the way NAV configures Cricket - you should use this as your starting point for /usr/local/cricket/cricket/subtree-sets . I don't know if the doc for the port mentions that factoid.
NAV v3.2.2
Ouch, that's old. Really hope someone updates that port.
You didn't mention what you found in getDeviceData-stderr.log and eventEngine-stderr.log?
Those files weren't being created. Now they are. ;-)
But getDeviceData and eventEngine are starting? Or failing? What are the errors in those files?
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.
I have no idea what "truss" is, but I'm assuming it's a FreeBSD tool that does something akin to strace on Linux?
Your truss output doesn't really give me any clues.
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?)
The files in /usr/local/nav/etc/cron.d/ are cron snippets that the nav command inserts into (or removes from) the navcron user's crontab. The nav command will read a file from /usr/local/nav/etc/cron.d/, then attempt to call the system crontab command (with the "-u navcron" option) to read the user's existing crontab and to write a new one. Could it be that the crontab command is hanging for some reason?
Besides, you say that "nav start alertengine" seems to stall, and this command will not modify the crontab, since alertengine isn't a cronjob but a daemon. It will however look at the files in the cron.d directory, and look at the navcron user's crontab with "crontab -u navcron -l".
If you could send a full truss output (with forks) of the "nav start alertengine", then maybe that would help (upload it to a pastebin or send it in a private e-mail so as to not bother the entire mailing list with it).