I follow the installation instruction to install and to get wildfire run as service. The installation is ok, I put wildfire dir under /opt. Then I turn to root and run redhat-postinstall.sh script. It create new user jive, put wirefired to /etc/init.d and create link to that file in /etc/rc3.d/. That’‘s look fine and wildfired service should automatic run when machine bootup but it’'s not.
I must go start it manually by “/opt/wildfire/bin/wildfire start”
notice that when I run “wildfire start” manually it will not return me a shell
The first think I would check is make sure the script is turned ON. Do this with :
chkconf --list wildfired
wildfired 0:off 1:off 2:on 3:on 4:on 5:on 6:off
It must read “2:on”, “3:on”, and at least “5:on” in the output. Also notice I have a “d” (for daemon) after the wildfire name. This is the real name of the script unless it was wrong in an older version.
If the script is not on, turn it on with:
chkconf --level 2345 wildfire on
As for manually starting it, I think you are getting you shell back, it is just printing something to the screen after your prompt is printed so it looks like the shell is waiting. Just press enter to get the shell prompt
Thanks karvin, you right, look like it print "nohup: appending output to ‘‘nohup.out’’(nohup.out is blank) after return a shell but chkconfig result is look OK. It should start on runlevel 2,3,4,5.
chkconfig --list wildfired
wildfired 0:off 1:off 2:on 3:on 4:on 5:on 6:off
my boot.log say wildfire is start ok but when i nmap it’'s no port 9090 open.???
grep wildfire /var/log/boot.log
May 2 11:11:54 fedev rc: Starting wildfired: succeeded
May 2 11:21:23 fedev rc: Starting wildfired: succeeded
May 2 12:36:10 fedev rc: Starting wildfired: succeeded
May 2 13:39:52 fedev rc: Starting wildfired: succeeded
May 2 14:21:29 fedev rc: Starting wildfired: succeeded
May 2 14:56:52 fedev rc: Starting wildfired: succeeded
May 3 09:34:09 fedev rc: Starting wildfired: succeeded
May 3 10:09:04 fedev rc: Starting wildfired: succeeded
If you did run Wifi as root and not as jive one time you should stop Wifi and run the redhat-postinstall.sh again to make sure that the permissions are right. Otherwise Wifi may not be able to open the log files etc.
No? Then I assume that your wildfired is stored as /etc/init.d/wildfired ?
Could you check if it is there and try to start / stop Wifi being root using it instead of /opt/wildfire/bin/wildfire ?
Maybe the “su” command fails, it you can’'t start it try to run “sh -x /etc/init.d/wildfired”, this could give you more useful output of what the script is doing.
I run “/opt/wildfire/bin/wildfire start” as jive so I think there is no permission problem(already check all log file in /opt/wildfire/logs/ are own by jive).
here is result of “sh +x /etc/init.d/wildfired start”
sh -x /etc/init.d/wildfired start
export WILDFIRE_USER=jive
WILDFIRE_USER=jive
‘’[’’ ‘’!’’ ‘’]’’
‘’[’’ -d /opt/wildfire ‘’]’’
WILDFIRE_HOME=/opt/wildfire
case “$1” in
start
execCommand start
++ pwd
OLD_PWD=/root
cd /opt/wildfire/bin
CMD=’’./wildfire start’’
su -c ‘’./wildfildfire start’’ jive
cd /root
exit 0
Starting wildfire
nohup: appending output to nohup.out’’ <<—need to press enter here to get shell back
what do you see in nohup.out if you start it as root using “/etc/init.d/wildfired start”? There are no errors, the “su” command seems to work fine, but I’'m not sure if it does as the username should imho be before “-c command”.
You could try as root:
cd /opt/wildfire/bin && su jive -c ‘’./wildfildfire start’’
and if this works edit the su command in the wildfired script.
nohup: appending output to nohup.out’’ <<—need to press enter here to get shell back
FWIW, you don’‘t need to press enter to truly get a shell back. You are still sitting at a command prompt, you just had the “Starting wildfire” and “nohup: …” stuff get outputted over it, but your input will still work just as if it hadn’'t happened. Hitting enter just redisplays a new command prompt.
Not that any of this is a big deal. I pretty much reflexively hit enter to redisplay the command prompt myself, even while knowing that its not really necessary. shrug
The joys of standard input and standard output (and standard error, fwiw) being different file descriptors.
I did grab a FC5 version and set a password for jive, this does not solve the problem. The file to edit for the other interested users is “/etc/selinux/config” and one may modify “SELINUX=enforcing” to “SELINUX=permissive” or “SELINUX=disabled” to get this solved and be aware of the impact his has on the system, if any.