I connect to a remote server using ssh -L but if I close the laptop lid or the connection is lost, the jupyter notebook is disconnected.
After I reconnect to the remote server, the "last" session is lost.
What can be done to make it persistent?
Could screen help with it?
On the remote server, you should open your jupyter in a screen session, it will make it persistent if you lose the connection to the server and resume it.
On your computer: ssh -L xxxx:localhost:yyyy server.
screen.
jupyter notebook --no-browser --port=yyyy. [on remote server]
In your browser: localhost:xxxx.
To disconnect manually and reconnect:
Exit the screen window: control + a and then d.
Disconnect from the server: control + d
And reconnect ssh -L xxxx:localhost:yyyy.
Optionally, you can reopen the screen window, though unnecessary, using screen -r.
Go back to your notebook or reopen localhost:xxxx.
The standard usage for persisting Jupyter server sessions is the use of nohup and &; in your remote server with IP address xx.xx.xx.xx:
nohup jupyter notebook --no-browser --ip xx.xx.xx.xx --port yyyy &
Now, even if you switch off your laptop or lose the connection, you will be always able to reconnect by pointing your browser at xx.xx.xx.xx:yyyy
Adding to #BiBi's answer...
Instead of screen I could recommend you to take a look at tmux. Especially, if you combine tmux with the Tmux Plugin Manager and install Tmux Resurrect, even after reboots of your remote server you will be able to go back to your previous Tmux sessions.
Shortcuts for tmux are somewhat equal to those of screens, just that control + a is replaced by control + b. Of course, tmux allows you to configure your custom shortcuts.
BiBi's answer is correct. But I had cases where my ssh connection terminated unexpectedly and the port forwarding no longer worked when trying to reconnect. Probably there was some dangling process on the remote machine, not sure.
Anyway, in these cases I used socat to proxy between two local ports on the remote machine:
# jupyter notebook/lab running in screen on port yyyy, then your connection dies...
ssh -L xxxx:localhost:zzzz
socat tcp-listen:zzzz,reuseaddr,fork tcp:localhost:yyyy
This way you can avoid restarting jupyter on a different port
Use the nohup command to keep jupyter running even after exiting the shell or terminal. Type the following command in the specified locations.
In remote server nohup jupyter notebook --no-browser --port=8085 > my.log 2>&1 < /dev/null &. This runs jupyter in port 8085 and any stdout would be present in my.log
In local ssh -NL 8085:localhost:8085 username#xx.xx.xx.xx. If port needs to be specified, you can use ssh -NL 8085:localhost:8085 -p xxxx username#xx.xx.xx.xx
In browser http://127.0.0.1:8085/
Sometimes port 8085 may be occupied in the remote server, in such cases try it with another port but make sure you use the same port number in the local while tunneling.
Related
I can join the port sucessfully by
ssh -N -L 8888:127.0.0.1:8888 server_ip
But if I just join the server, and then use jupyter notebook, I can't open the port sucessfully.
ssh server_ip
jupyter notebook --port=8888
Error:
The port 8888 is already in use, trying another port.
What is the reason and how to solve it?
You can check which application is currently running on port 8888 by following commands on Linux machine. If in case it happens to be an existing jupyter, you may try killing that process and start a new one.
Check current process running in 8888
lsof -i:8888
To kill the current process.
kill $(lsof -t -i:8888)
To forcefully kill the current process
kill -9 $(lsof -t -i:8888)
If for some reason you wish not to kill the current process, you may try launching jupyter on a different port.
jupyter notebook --port=8889
Sounds like you have some other process on port 8888.
You can either:
1) Kill the process on port 8888 and then launch jupyter-notebook on port 8888
2) Launch jupyter notebook on a different port and then use ssh to connect to the new port
I have several long running scripts (in Jupyter Notebook) on a remote Google Cloud Compute Instance.
If I lose the ssh connection, I cannot reconnect to the (running) Notebook without stopping those running scripts--executing within the Notebook.
It seems that closing my macbook, will sever my connection to the remote (running) jupyter notebook. Is there some way to reconnect without stopping the script?
On Google Cloud, Jupyter is still running. I just can't connect to the notebook executing the code––without stopping code execution.
I'm sure other Jupyter users have figured this out :)
Thanks in advance
My GCloud Tunneling Script
gcloud compute ssh --zone us-central1-c my-compute-instance -- -N -p 22 -D localhost:5000
Bash Script that Launches Chrome
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome
"localhost:22"
--proxy-server="socks5://localhost:5000"
--host-resolver-rules="MAP * 0.0.0 , EXCLUDE localhost"
--user-data-dir=/tmp/
Nohup that launches Jupyter on Gcloud
nohup jupyter notebook --no-browser > log.txt 2>&1 &
On my Sierra-os macbook, no proxy settings (System Preferences) are enabled
On Google Cloud, I'm NOT using a static ip, just an ephemeral ip.
Much appreciation in advance
What do you mean by "cannot reconnect" ? Do you mean you can't see the notebook interface anymore ? (In which case this is likely a google cloud question).Or do you mean you can't run code or see previous results ?
If the second, this is a known issue, the jupyter team is working on it; The way to go around that is to wrap your code in Python Futures, that store intermediate code; thus re-accessing the future will not trigger re-computation, but will show you intermediate results.
I am connected to a Linode terminal via SSH.
I have started a Jupyter Notebook server from the command line.
But I want to do some other tasks in the command line, keeping the NB server running. I can't work out how to do this without stopping the Jupyter Notebook server. It says:
[I 05:55:05.523 NotebookApp] Use Control-C to stop this server and shut
down all kernels (twice to skip confirmation).
Since you mentioned Linode, I'm assuming it is on a linux/unix system.
Possbile options:
Send process to background
send process to background: jupyter notebook &
do some work on terminal
close jupyter with pkill jupyter (this should have the same effect as
a ctrl+c keypress)
WARNING: this will kill all jupyter instances
use a terminal multiplexer like tmux
just use multiple ssh sessions (not really elegant imo)
Overall, I think the option that would be easiest and most flexible is option 2.
I am trying to get GNU parallel to split up a processing job between my machine (Win7 running Cygwin) and some remote machines (Linux).
But I can't seem to figure out the syntax to do both from the same command. I have tried using -S localhost, user#server1, user#server2 but (localhost) does not have sshd running, so this fails (the job does continue running on the remote hosts).
Thanks in advance.
From man parallel:
The sshlogin : is special, it means no ssh and will therefore run on the local computer.
i was created a bash script my_vp.sh that use 2 command:
setterm -cursor off
setterm -powersave off
[...]
#execute video commands
[...]
and is in a computerA
but when i execute it by ssh by another computerB_terminal:
ssh pi#192.168.1.1
execute video commands work correctly in the computerA (the same where is the script)
but the command setterm works in the computerB (the terminal where i execute the ssh command).
somebody can help me with solucione it?
thank you very much!
I am not sure I understood the question:
to execute a local script, but on another machine:
scp /path/to/local/script.bash pi#192.168.1.1:/tmp/copy_of_script.bash
and then, if it's copied correctly, execute it:
ssh pi#192.168.1.1 "chmod +x /tmp/copy_of_script.bash"
ssh pi#192.168.1.1 "bash /tmp/copy_of_script.bash"
to have the remote video (Xwindows, etc) commands appear on the originating machine:
replace : ssh with : ssh -x (to allow X-Forwarding, which will allocate a DISPLAY automatically on the remote machine that will be tunneled back to the originating machine)
for the X-forwarding to work, there are some requirements (usually ok by default, but ymmv) : read more about those requirements in this Unix.se answer