Anders, On Saturday 09 April 2005 14:20, Anders Norrbring wrote:
...
Randall,
I don't know much about the jar file itself, it's the Azureus BitTorrent client. I guess I can find out somehow by unpacking it, or is that not possible?
In all likelihood, it is equipped with the necessary annotations. If "java -jar jarfile.jar" launches the program, then that's probably all you need to know (aside from any arguments and options specific to the program itself). If not, then the documentation should tell you how to launch the program. You can unpack a JAR file using either the "jar" command or the zip, unzip and zipinfo commands (JAR files are the same format as PKZip files).
Anyway, I tried what you suggested about a new directory, but no file was written to it. Startproc displays the pid when it exists, but that's the only trace I can get without running a ps to look it up manually, which isn't good since I want to run it scripted.
I've never used startproc, so I don't know what the deal might be with it, but it wouldn't hurt to give the precise invocation you're using as well as "ls -l" (or -ld) listings of the various files and directories you're using so we can see what might be going wrong.
Startproc isn't a "must", I can start it with screen instead if that will make any difference. I thought I could make use of the bash $$ somehow, but it seems like I can't get it to echo the java process pid, but only the pid "before", the parent script's pid that is...
The value "$$" is the shell's process ID. Ordinarily shells fork (creates a new process) for each command executed, whether entered interactively or via a shell script. However, you can cause the shell to overlay itself with the new program (irreversibly) by using the "exec" built-in. In that case, the command so executed will be the same process as the shell a hence will have the same process ID. So something like this will leave a reliable record of the server's process ID: echo $$ >|.../server.PID exec java -jar jarfile.jar # Nothing from here on will be executed
Any other suggestions?
Are you sure killing the program is the proper way to shut it down? Java does not provide any mechanisms that allow the program to intercept signals and perform clean-up operations before exiting. I'd look through the documentation to see if there's a better-controlled way to shut down the server. Often such servers will accept operational commands through a special port, possibly only from processes connecting from the same machine on which it runs (for security purposes).
Anders.
Randall Schulz