i just made a clean install of centos 4.3 and run the following commands to install wildfire
rpm -ivh wildfire_3_0_1.rpm
cd /opt/wildfire
sh bin/extra/redhat-postinstall.sh
reboot the system
my problem is this, during the reboot process, the console displays that '‘Starting wildfired: ‘’, but when i log on the console after the reboot and did a ‘‘ps -ef’’, wildfire process was not running. i have to manually do a ‘‘service wildfired start’’ in order to run wildfire. can anyone tell what i’'m missing here.
below are the messages i got from /var/spool/mesages
Sep 8 17:20:45 localhost su(pam_unix)[1981]: session opened for user jive by (uid=0)
do you have SELinux enabled? If you do it may help to execute “/usr/sbin/setenforce 0” before the “su” command and “/usr/sbin/setenforce 1” after it as documented in http://wiki.jivesoftware.org/display/WILDFIRE/LinuxInstallationGuide
i tried verifying the status of selinux by running the sestatus command found out that selinux is already disabled. any thoughts how i should resolve this?
my problem is this, during the reboot process, the console displays that '‘Starting wildfired: ‘’, but when i log on the console after the reboot and did a ‘‘ps -ef’’, wildfire process was not running. i have to manually do a ‘‘service wildfired start’’ in order to run wildfire. can anyone tell what i’'m missing here.
My guess is that CentOS is indeed a RedHat flavor. In RedHat ‘‘ps -ef’’ won’'t show you that Wildfire is running. Use ‘‘ps auxw | grep wildfire’’ instead. Kill all the java processes that runs wildfire and restart wildfire ‘‘service wildfired start’’, or simply reboot your server. Then try to login to http://yourhost:9090.
so you may want to stop / kill Wildfire, delete the Wildfire log files and reboot your server. As the server does the su - jive switching you should see something in the Wildfire log files. Also nohup.out should be created.
the console is not accessible after the reboot which proves that the service was not running. but after manually doing a ‘‘service wildfired start’’, the console is already accessible. any more thoughts from you guys?
as suggested by aznidin, i tried changing /etc/init.d/wildfired line that says ‘‘chkconfig: 2345 20 80’’ to ‘‘chkconfig 2345 85 80’’ but still rebooting the system won’'t start wildfire.
I think anyone who has centos 4.3 could replicate this problem since i’'ve done a couple of fresh installs already but still unsuccessful and its getting a bit frustrating.
Lets see… you could do “service wildfired start” manually, that means the wildfired script is fine. What are you getting when you do “chkconfig --list wildfired” ?
Yeah, worse comes to worst, that rc.local trick Gene mentioned should work.
This is really wierd. Inspite of my little experience on CentOS OS installation, I managed to install and run a complete CentOS-built clustering suite (from DRAC fencing till GFS) on my RedHat machines, and it worked seemlessly. I wonder what’'s so special about the rather primitive SysV startup, that it takes a lot more troubles to get it work than it is with a clustering suite.
calling wildfire in /etc/rc.d/rc.local did the trick.
but i think this issue needs to be addressed since this technique is not part of the normal installation procedure and if left unresolved, future newbies would encouter similar problem.
btw, running chkconfig --list wildfired shows the following: