Our preference for deploying Jive Messenger / Wildfire is to do so under Dan Bernstein’'s url http://cr.yp.to/daemontools.htmlDaemontools[/url]. The one problem that we ran into was that the default script nohups and backgrounds the process when using the “start” operation. This spins the java process off into a separate pid so that Daemontools thinks that it died once the script exits and proceeds to attempt to start it again. The solution is to copy the “start” block in the “case” near the end and adjust it as follows:
The current script is what install4j builds automatically, so it’‘s tough to get changes to it in place. However, it might be a better idea to just build our own script by hand and use that instead. If you look at the nightly builds, we include a .sh script that would probably be a good start. I’'m definitely interested in feedback on this.
I’‘d have to agree with Craig that the nohup & background line is not optimal. A proper /etc/init.d script performs some actions based on PID, but launching Wildfire in a separate process makes getting that PID harder. Just so I don’‘t have to constantly edit the startup scripts, I’'ve set my /etc/init.d script to actually search out processes that look like they could be Wildfire, then record the PID from it/them. A line like Craig suggested would make the PID detection much easier and robust, and would make Wildfire easier to manage in general.
I started Wildfire only one time with the supplied start script. Imho it is not usable for a production system. It looks for installed java versions and this takes a long time, especially if you have ten different versions on your server. Actually it did fail because there was no java 1.5 on this server, but this is another story.
I use set and set -x to get the needed environment variables and the java call with all parameters and transfer these information into a proper start script.
I think that in the sample script the classpath is not exported but supplied with “java … -classpath $classpath …” to the java process. I prefer “export classpath” and “java …” which leads to a much shorter start command, so I changed not only this. I don’'t want
But the start script has so much parameters, I wonder why no “.ini” or “.xml” file is used, so there would be no need to change the start parameters with every new release. If a change of the start parameters is necessary it would be easy to detect. Many people have no idea what these parameters are used for: ‘‘true 0 0 “” 20 20 “Arial” “0,0,0”’’ - a config file usually contains some examples and a short documentation.
As someone new to Wildfire and Java Apps in general, I’'ve got to agree with the previous post.
I too prefer to use daemontools to supervise long-running services, but having looked at the wildfire run script it seems extremely complicated for something that is essentially just running a program.
I would echo the suggestion that most of this should go in a config script and that run script should be much more simple.
I edited the messenger script to remove the nohup and & at the end. In my case, I just wanted to use supervise, and the other points in this thread where not as important to me as to other people.
I would like to have a foreground version of the startup script, but for now, I don’'t mind working around this issue.
One thing I’'m still struggling though, is how to redirect the logs to stdout/stderr.
The install4j startup thingie does some redirecting of the stdout/stdin. Does any body knows how to disable the log-to-file so that I can use multilog (also in the daemontools package) to manage my log files?
The last two parameters specify where the logs should go to. For now I’'m using “” as both parameters, and it seems to work. But is it really working or am I just lucky?
If anybody know install4j, any help is appreciated.