When I run the rpm on a Redhat ES4 server, everything looks normal. I can run the “redhat-post-install” just fine. I even got the schema loaded into the MySql database. But when I go to execute the actual server, it tells me that it is outputting everything to nohup.out. When I edit this file, there is absolutely nothing in there and the service has not started. Can anyone help me out here?
Welcome to Jive community
Since you install wildfire using its rpm, I suppose the installation directory is in /opt/wildfire. There are a few log files in /opt/wildfire/logs directory which might give you some clue.
Also, whathappens when you go to http://localhost:9090/
Does it give you the setup screen?
There are a lot of lines in the stderror.log and when I check the admin-console.log, it simply says “Error starting admin console: Multiple exceptions”. I haven’'t seen anything to point me in the right direction as of yet.
When I go to the :9090, I get the 404 not found error. This is not surprising as the wildfire service will not start. When I look for it using “ps -e |grep wildfire”, there is no listing for it. I see “java” in the list, but never wildfire or wildfired.
Can you post your config file
Which one? wildfire.xml?
the file nohup.out will be empty, this is normal.
Which user is running Wildfire?
Try “ps -ef|more” and not “ps -ef|grep …” as this may cut the output to 80 characters so you won’'t see wildfire in the command line.
A “ps -fu wildfireuser” shoud also display that java is running.
Try to post the first error you see in logs/error.log.
Here it is. I removed all the logs and tried starting the service again so that I would have a fresh sample. This is the first part of it. Let me know if any more would be helpful.
2006.08.24 15:03:49 org.jivesoftware.wildfire.container.AdminConsolePlugin.initializePlugin(AdminCon solePlugin.java:197) Trouble initializing admin console
org.mortbay.util.MultiException[java.net.BindException: Address already in use, java.net.BindException: Address already in use]
at org.jivesoftware.wildfire.container.AdminConsolePlugin.initializePlugin(AdminCo nsolePlugin.java:191)
at org.jivesoftware.wildfire.container.PluginManager.loadPlugin(PluginManager.java :396)
at org.jivesoftware.wildfire.container.PluginManager.access$200(PluginManager.java :47)
at org.jivesoftware.wildfire.container.PluginManager$PluginMonitor.run(PluginManag er.java:883)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101 (ScheduledThreadPoolExecutor.java:65)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodi c(ScheduledThreadPoolExecutor.java:142)
Wildfire tries to open port 9090 and 9091. So either Wildfire is still running or you have another application running on port 9090.
If you are sure that another application uses port 9090/9091 then stop Wildfire and change then 9090/9091 in conf/wildfire.xml to free ports.
I appreciate the heads up on that one, but the service won’‘t even start. I’'m stuck at the service telling me that it is starting and then printing “nohup: appending output to ‘‘nohup.out’’”. When I then check to see if the service is running, it does not appear. Just to be sure that this was not in conflict with another port, I did change the port to something open in the wildfire.xml. Same result.
The BindException: Address already in use states that an application server already listens to specifically port 9090/9091. If you run netstat -ln | grep 9090 you should be able to see an entry. I think you already have Wildfire running. Try ps auxw | grep wildfire, instead of ps -e | grep wildfire.
If you see 404 error at http://localhost:9090 then it’‘s probably something else. To investigate that, perhaps you’'d want to kill -TERM all pid you get from ps auxw | grep wildfire, remove all files in logs/, restart wildfire service wildfired start, try http://localhost:9090, and if you still got 404, post the logs/error.log here again.
the nohup.out file should stay empty. Try a “netstat -an 9090” or the port you did use and you’'ll see that it is running. The log files should be empty and http://domain:9090/ should open the Wildfire web page or create some entries in the error log file.
If you call “/etc/rc.d/init.d/wildfired start” and SELinux is enabled then it may be possible that Wildfire will no start, you should see a message in /var/log/messages. Try to start it as user “wildfire” or “jive” or whatever you use with “/opt/wildfire/bin/wildfire start”.
You are awesome! I had no idea that it was actually spinning processes like that. I thought it was stopping at the nohup.out statement. Once I killed those and restarted the service, all was well. Now I can actually get to the setup screen. Thank you so much.