Life after closing your terminal window

In the past posts, I shared a lot of nodejs code to run mostly your code unattended. A few commenters pointed out that the data stops getting recorded when they kill their remote session.
There are multiple ways to skin this type of cat. Here’s what you do in practical terms.

Tools

  1. Screen
  2. Tmux
  3. nohup
  4. forever (specific to nodejs)
  5. cheap trick
Screen it has been long on the Linux scene, it allows you to interact with your remote session, resume from where it is, or you have left it. It’s not a piece of cake to use if you have not educated yourself about it.
This quick (2 min) tutorial gives you a quick jumpstart about it. However, if you do want to use, take a look at this quick reference.
It doesn’t come installed with Jesse on Rasbian use the following to install it
sudo apt-get install screen
to execute your code
screen -d -m node --mycodefile.js

Screen has been around for a long time, less seasoned but with many more other advantages is Tmux. I prefer it over Screen for many reasons. If you want others people opinion between the two take a look at this post.
This video tutorial can give technical insights and basic operational paths. It’s well done. Thank you, Sam!
Tmux comes already installed, with Rasbian and that’s an additional plus. If you stick with that, this quick reference will come handy for sure.
That boils down to the following steps
  1. Login
  2. tmux
  3. kick whatever process you want with/without redirecting I/O
  4. close your terminal window
  5. When you’re ready to peek in again log in
  6. type tmux attach
You’re welcome ;-)

nohup is a POSIX command to ignore the HUP (hangup) signal. The HUP signal is, by convention, the way a terminal warns dependent processes of logout.
That is straight from Wikipedia, and it is in an essence all you need to know to use. To have your nodejs code running even after you kill your remote shell window use this command:
nohup node my_code.js > /dev/null 2>&1 &
Breaking that down
> /dev/null means everything that you would normally see in the console (stdout) will go in the void. Not recorded. The program will not even notice the difference.
2>&1 means if an error occurs (stderr) do the same as above. However more than often you want to keep an eye on errors, and you may change that to 2>/var/mylog or whatever floats your boat in terms on naming and places to store temp files.
The ampercand (&) at the end means to run the process in the background.
If you want to take this to the next level add the following function your .bash_profile so that you have it handy for future use.
nohup-template () {
    [[ "$1" = "" ]] && echo "Example usage:\nnohup-template urxvtd" && return 0
    nohup "$1" > /dev/null 2>&1 &
}
In general terms you can use the ampersand at the end of your command. That is what I call cheap trick. You milage vary a lot based on the distro and configurations.  Take a look at this post which informs you a ton about the usage and various options around that.

The basic rundown is that you run 
node foo.js & 
or 
node foo.js &!
The first case runs in the background without disowning the process while running in the background; the later does perform the disowning part as well.
When you kick off a process in the background with the ampersand remember that you won’t see anything running on the screen (if you did it right :-) and that begs the question: how do I stop or restart THAT process?
Fear no more skywalker. Entering two key commands: jobs and fg. Below an example of use:
node myserver.js > /dev/null 2>&1 &
That will kick the process in the background and hide the printout. If you want to switch that to foreground you might use jobs to get the associate ID to that job and that then
fg %1
When the process get stuck and you got to kill the pending process knowing the PID (process ID) lets you do that. To find the associated PID, use this:
ps -A | grep -m1 process_name | awk '{print $1}'
kill PID
Plenty of other options in this regard here.
Note of caution: if the process has been disowned you will have to look beyond your user session and you can do that with this
ps -ef | grep my_server_code
kill PID

Specifically, for nodejs take a look at forever module. Easily installed with 
npm install forever -g
and to use it just run
forever start my_code.js
Your last resort is to create a daemon like that runs your code on boot, but that takes you in a dark place if you need this post to clarify your mind on this subject. In that case, it’s fair to assume that without learning deeply about it, could be out of your comfort zone and might not be worth it all.

Conclusion

It’s a jungle of options, and it’s hard to find all this information in one place. Hence, the comments on other posts lead me to realize that would have been a good service to myself in future and the community to share away.

References

Comments

Popular posts from this blog

Postgres on Synology

The Making of Basculo

Build an independent watch app - Part II