powered by Jive Software

Cannot start wildfire upon boot-up with CentOS 4.3

i just made a clean install of centos 4.3 and run the following commands to install wildfire

  1. rpm -ivh wildfire_3_0_1.rpm

  2. cd /opt/wildfire

  3. sh bin/extra/redhat-postinstall.sh

  4. 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)

Sep 8 17:20:45 localhost rc: Starting wildfired: succeeded

Sep 8 17:20:46 localhost netfs: Mounting other filesystems: succeeded

Sep 8 17:20:47 localhost su(pam_unix)[1981]: session closed for user jive

Hi,

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

LG

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?

Hi Jet,

jet wrote:

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.

Hope that helps.

Hi,

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.

LG

Hi LG,

it2000 wrote:

Also nohup.out should be created.

In Jet’‘s setup, I don’'t think that is applicable.

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?

What did you see in /opt/wildfire/logs/*.log files right after boot up but before you manually run “service wildfired start”?

I wonder if your problem relates to the bug that I reported here.

the log files doesn’'t show anything which probably means that wildfire was not really executed during the bootup.

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.

does anybody encountered this problem before and what was your solution?

I beat it up pretty well, but failed to find a fix to the /etc/init.d/wildfired script.

BTW, my install is on Centos 4.4.

You can start Wildfire the old fashioned way:

Edit /etc/rc.local and add:

  1. Start Wildfire IM Server

su -c “/opt/wildfire/bin/wildfire start” jive

Message was edited by: gcooper

@Jet:

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:

wildfired 0:off 1:off 2:on 3:on 4:on 5:on 6:off

I use CentOS too, version 4.1, And I also meet this problem.

Make sure you database service starts upon boot-up and before Wildfire starts.