google cloud instance terminate after close browser

Question

I have a bash script. I would like to run it continuously on google cloud server. I connected to my VM via SSH in browser but after I've closed my browser, script was stopped. I tried to use Cloud Shell but if I restart my laptop, script launches from start. It doesn't work continuously! Is it possible to launch my script in google cloud, shut down laptop and be sure what my script works?

Answer 1

The solution: GNU screen. This awesome little tool let's you run a process after you've ssh'ed into your remote server, and then detach from it - leaving it running like it would run in the foreground (not stopped in the background).

So after we've ssh'ed into our GCE VM, we will need to: 1. install GNU screen: apt-get update apt-get upgrade apt-get install screen

2. type "screen". this will open up a new screen - kind of similar in look & feel to what "clear" would result in.
3. run the process (e.g.: ./init-dev.sh to fire up a ChicagoBoss erlang server)
4. type: Ctrl + A, and then Ctrl + D. This will detach your screen session but leave your processes running!
5. feel free to close the SSH terminal. whenever you feel like it, ssh back into your GCE VM, and type screen -r to resume your previously detached session.
6. to kill all detached screens, run: screen -ls | grep pts | cut -d. -f1 | awk '{print $1}' | xargs kill

Answer 2

You have the following options:
1. Task schedules - which involves cron jobs. Check this sample. Via this answer;
2. Using startup scripts.

I performed the following test and it worked for me:
I created an instance in GCE, SSH-d into it and created the following script, myscript.bash:

#!/bin/bash          
          sleep 15s
          echo Hello World > result.txt

and then, ran
$ bash myscript.bash
and immediately closed the browser window holding the SSH session.
I then waited for at least 15 seconds, re-engaged in an SSH connection with the VM in question and ran $ ls and voila:
myscript.bash result.txt

So the script ran even after closing the browser holding the SSH session.
Still, technically, I believe your solution lies with 1. or 2.