bash process management - ghdrako/doc_snipets GitHub Wiki
Run something in the background and then log out.
If you want to be able to reconnect to it later, use screen or tmux. Launch either, then run whatever you want to run in the foreground, and detach (screen with Ctrl-A d and tmux with Ctrl-B d). You can reattach (as long as you didn't reboot the server) with screen -x to screen and with tmux attach to tmux. You can even attach multiple times, and each attached terminal will see (and control) the same thing.
If you can't or don't want to do that, the traditional approach still works: nohup something &
Bash also has a disown command, if you want to log out with a background job running, and you forgot to nohup it initially.
sleep 1000
Ctrl-Z
bg
disown
If you need to logout of an ssh session with background jobs still running, make sure their file descriptors have been redirected so they aren't holding the terminal open, or the ssh client may hang.
Run two jobs in the background, and then wait until they both finish.
job1 &
job2 &
wait
You can specify one or more jobs (either by PID, or by jobspec -- see Job Control for that)
check to see if server is still running? I'll put a script in crontab, and if it's not running, I'll restart it
Most Unix systems already have a feature that allows you to respawn dead processes: init and inittab. If you want to make a new daemon instance pop up whenever the old one dies, typically all you need to do is put an appropriate line into /etc/inittab with the "respawn" action in column 3, and your process's invocation in column 4. Then run telinit q or your system's equivalent to make init re-read its inittab.
Some Unix systems don't have inittab, and some system administrators might want finer control over the daemons and their logging. Those people may want to look into daemontools, or runit.
Unix/BSD people came up with workarounds... they created "PID files", in which a long-running daemon would write its process ID, since the parent had no other way to determine it. But PID files are not reliable. A daemon could have died, and then some other process could have taken over its PID, rendering the PID file useless. Or the PID file could simply get deleted, or corrupted. They came up with pgrep and pkill to attempt to track down processes by name instead of by number... but what if the process doesn't have a unique name? What if there's more than one of it at a time, like nfsd or Apache?
These workarounds and tricks are only in place because of the original hack of self-backgrounding. Get rid of that, and everything else becomes easy! Init or daemontools or runit can just control the child process directly. And even the most raw beginner could write their own wrapper script:
#!/bin/sh
while :; do
/my/game/server -foo -bar -baz >> /var/log/mygameserver 2>&1
done
Then simply arrange for that to be executed at boot time, with a simple & to put it in the background, and voila! An instant one-shot respawn.
Most modern software packages no longer require self-backgrounding; even for those where it's the default behavior (for compatibility with older versions), there's often a switch or a set of switches which allows one to control the process. For instance, Samba's smbd now has a -F switch specifically for use with daemontools and other such programs.
If all else fails, you can try using fghack (from the daemontools package) to prevent the self-backgrounding.