New FC4 Install - Problems w/startup?

Fedora Core 4 Linux

Installed using freshly downloaded RPM v.3.1.1 including JRE

./wildfire start

nohup.out shows:

Starting wildfire

ps aux shows:

/opt/wildfire/jre/bin/java -server -Dinstall4j.jvmDir=/opt/wildfire

netstat -a shows:

tcp 0 0 *:9090 : LISTEN

tcp 0 0 *:9091 : LISTEN

service iptables status | grep 9090 shows:

ACCEPT tcp – tcp spt:9090

./wildfire status shows:

Usage: ./wildfire {start|stop}

(which is displayed when Wildfire is not running …)

./wildfire stop “stops” Wildfire, apparently, as ps and netstat no longer show it

I also tried:

cd /opt/wildfire/bin/extra


service wildfire start

and saw all of the same stuff as ./wildfire start, but still no status and no joy.

Can’‘t connect to http://MY.IPA.DDR.ESS:9090, and as this is a remote system, I can’'t do localhost.

Any thoughts? I really appreciate it.


Wildfire is usually running fine if port 9090 is open.

As this is not an iptables forum you should probably ask this question not here but as you already did ask …

I wonder how “spt:9090” will help you if you have a firewall on your server. You want connect to port 9090 so “ACCEPT dpt:9090” should be the right setting.


Thanks a lot for your response.

I’‘ll say “doh” regarding the iptables setting (“doh!”), however even with it set as destination port using either TCP or UDP (tried both, just in case) I can’'t get to the admin/setup page.

(I previously included the iptables info, as part of the troubleshooting.)

Additionally, in /var/log/messages, I see something like this after a start attempt:

Dec 9 13:27:26 boxname su(pam_unix) [5219]: session opened for user jive by (uid=0)

Dec 9 13:27:26 boxname su(pam_unix) [5219]: session closed for user jive

So, to sum up:

  1. Wildfire is apparently started because port 9090 is listening and it’'s listed in ps(?)

  2. The firewall is allowing TCP (and/or UDP) traffic to port 9090

  3. I still can’'t get to the admin/setup page remotely

Now that the iptables issue is ironed out, what else should I be looking at? Thanks, again.


on your server “wget -O -” should display you the setup page on your terminal as Wildfire is running.

I wonder if you also accept state NEW or only established connections. You only need TCP to get HTTP working.

The clients will later use port 5222, also TCP to connect to the server.


Okey doke …

The wget command did indeed pull up the code for the index.jsp page, so I connected to it using

“lynx” and completed the initial setup sequence. I need a Javascript-enabled browser to go any further with the setup, though.

Still can’'t get there from here with Mozilla, MSIE6, or v7 on another system, or with Firefox.

Firefox reports a connection timeout.

My iptables are set for NEW connections, and all the other stuff (except dpt:!) is being reported as it was.

I added the Wildfire service to PAM, and I’'m running wildfired successfully, in that “service wildfired status” returns “wildfire is running”. When I started the wildfired service I got the same /var/log/messages su(pam_unix) tail as before; opened and closed session for jive within the same second.

It’‘s a little odd. I’'m running other services like Webmin and a couple of community sites like Jamba and more.groupware with no authentication problems.

I do appreciate your continuing observations, it2000!


if it is not the firewall on your local server you may have a firewall somewhere else. You could enable iptables logging for all SYN packets to see if it does receive your server if you try to connect to port 9090.

Without messing around with the firewall you could

a) Use another port which for sure forks, eg. 8080 (to be configured in conf/wildfire.xml)

b) Use a ssh tunnel if this is allowed by the sshd on your server.


Not logging any SYN requests on port 9090, so there’‘s something else going on. I modified the config file’'s insecure port setting to any one of the (slightly offbeat) ports (like, not 80) that are open and available with the same results.

What about the ‘‘jive’’ user? Is it supposed to be able to login?

I saw another post in these forums that described /var/log/messages’’ output as something like:

Dec 11 12:45:43 mail su(pam_unix)[27463]: session opened for user jive by (uid=0)

Dec 11 12:45:44 mail su(pam_unix)[27463]: wildfire startup stuff

Dec 11 12:45:45 mail su(pam_unix)[27463]: more wildfire stuff

Dec 11 12:45:48 mail su(pam_unix)[27463]: session closed for user jive

I’'ve never been able to get anything other than the ~1 second transaction:

Dec 11 12:45:43 mail su(pam_unix)[27463]: session opened for user jive by (uid=0)

Dec 11 12:45:43 mail su(pam_unix)[27463]: session closed for user jive

The jive user and group are established, however jive user is set to temporarily disable login. If I remove that flag, jive gets set to no password required. I can’‘t locate anything that would allow me to establish/change jive’'s password so it actually uses one without getting set to temporarily disable login. Is this normal?

Wildfired is definitely starting and using resources and the ports it uses are free and clear, so I’‘ve got to imagine, given the evidence, that it’'s a jive user issue of some kind.

Here’'s the tail of my info.log file. Note the timestamp in relation to the /var/log/messages timestamp above for the same startup attempt:

2006.12.11 12:45:48 Multi User Chat domain:

2006.12.11 12:45:48 Publish-Subscribe domain:

2006.12.11 12:45:48 Started server (unencrypted) socket on port: 5269

2006.12.11 12:45:48 Started plain (unencrypted) socket on port: 5222

2006.12.11 12:45:51 Started SSL (encrypted) socket on port: 5223

2006.12.11 12:45:52 Wildfire 3.1.1 [Dec 11, 2006 12:45:52 PM]

2006.12.11 12:46:03 Admin console listening at:

Looks pretty normal. No errors in the other wildfire logs … Normal?

Thanks again, it2000.


your start script may contain “su -c ./wildfire start jive &” and you may run it as root as all rc scripts are run by root but the Wildfire server process runs as jive which is fine. And it takes just a second to execute this.


I wish I had better news, but here it is …

I uninstalled wildfire and removed any related entries in my iptables.

I did a fresh install and added the same iptables entries as before.

Everything works.

(It’‘s bad news because I don’'t have a reason why it behaved as it did before, so not much to learn from.)

I really appreciate the time you took with me, LG/it2000. Have a great holiday season!