Richard S. Hall: > Vegar Westerlund wrote: >> Is this the recommended way of running Felix as a daemon? Summary: >> >> * Disable shell.tui (by removing the autoload paramater) >> * Set felix profile (-Dfelix.cache.profile=<some-profile>) >> * Redirect stdout and stderr to some log file ( >> felix.out 2>&1 ) >> >> e.g: >> (cd ~/felix-trunk/main; java -Dfelix.cache.profile=myProfile -jar >> bin/felix.jar) >> /var/log/felix.log 2>&1 & >> >> Is there an init-script that does this (possibly in a cleaner way...)? > > No, I think that is it. Now you might think about including shell.remote > so you can remotely access the Felix shell (or the web console).
Sure. > Felix itself doesn't make any attempt to use stdin, but the simple > launcher does (i.e., it assumes it can ask for a profile if one doesn't > exist and is configured to autoload the shell.tui), but it is > configurable to avoid doing these things. «the simple laucher does...»? Is felix normally run from another application (like I guess it is when running Eclipse)? I would like to run Felix on a server to be a backend for business logic. And then I only want to start the Felix server. > How would you like it to be cleaner? Do you mean having it set up as a > daemon automatically? Most programs designed to run as a daemon will ensure that stdout and stderr are redirected to syslog (or a logfile) and stdout are closed before forking a process to run in the background. And possibly a debug mode where the console are kept as output. Thats what I was expecting, but didn't find. > We have some work started on an installer that will automatically > install Felix as a daemon, but unfortunately that has stalled. Yeah, I read about something in the archive from November 07 about using Java wrapper. I tried it out and it seems to work on our Linux server. -- Vegar Westerlund --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
