None of these seem like the right way to be running a server.
Agreed!
On Linux, you typically run things using either the newer upstart/services system, or the more mature init.d system. Or, if you're really old-school, the /etc/rc.local system :-)
There are a few things you need for a real service:
1) Any logging output from the server needs to be preserved in a file, and archived for a while, but eventually removed. Otherwise the hard disk would fill up.
Syslog if fantastic for this, because /var/log/messages gets rotated once a week, and purged after a few weeks, by default, on most Linux installations.
If your program just prints to stdout (or stderr) then you can turn it into a syslog-using program by piping the output to "logger -t yourname"
A typical server start command line might look something like:
(/path/to/java /path/to/mygame.jar </dev/null 2>&1 | logger -t mygame) &
What this does is tie the standard in of the game to /dev/null (so it doesn't die when you log off), tie standard error to standard out, and send standard out to the logger process so it goes to syslog. Finally, it runs all of that in the background, so the command line comes back immediately. You can see the process(es) running with "ps axf" or perhaps "top". At that point, you should probably also look into the "kill" command if you want to be able to stop it :-)
2) If the process is already running, you probably don't want to start a second copy. This is generally handled through a file in /var/run/ that you create and put your process ID in when the process starts, and that gets removed when you shut down the process. However, if the process crashes, that file may stay there, and need to be removed. A typical construct is to make the start script for your server do something like: * does /var/run/myname.pid exist? If so, complain and exit! * start the process * put the PID of the started process into /var/run/myname.pid
Note that there is a race condition there if you try to start the same process twice at the same time. There are fancier ways to solve this problem (see: upstart)
3) If the process crashes, you may want something to happen. Should it send you SMS? Should it log something? Should it auto-restart? If it auto-restarts, what if it crashes on start, and goes into an infinite restart loop? The specific requirements here are different for each system. Generally, you'll want to put a second script around this behavior that monitors and restarts the service, or whatever should happen.
4) Starting the service automatically when the server boots. If there's a link in /etc/rc2.d (or rc3.d) called S99myname, and it points at your init script (typically in /etc/init.d, called yourname) then that init script will be called with the argument "start" when the system boots. You can make arrangements for that script to start the server by putting the right code in that script. Traditionally, that script should also recognize a "stop" command (for ordered shutdown, removing lock files, etc) and "reload" (for re-loading configuration files while still running). For a more ghetto option, you can put a line into /etc/rc.local -- that file runs once, on system boot, and can start services that don't need other management.
).
