I have been working on my R studio session hosted by a Linux server and recently, ran a piece of code that was taking way too long to execute and I decided to kill it.
Here is the sequence of steps that I took - none of them helped me restore the health of my session.
1) Hit the stop button on R studio and be patient.
2) Ssh into my Linux server and ran the following command to kill all the processes running with my userid
killall -u myuserid
3) Removed the.RData,.Renviron,.Rhistory files from my workspace.
4) Ran the following R command via the Linux server for garbage collection
gc(reset=TRUE)
4) Restarted the entire Linux server.
I am running out of ideas and would really appreciate any other suggestions before I take more drastic steps like revoking access and granting it again(not sure if that would be the right fix)
Note: The browser window freezes every time I login, and it happens only for my R studio session, the rest of the users in the same network have no issues.
I solved this problem - Rstudio-serverfreezing. I think it was a network problem since I couldn't receive any response from calling "~~~~~~.cache.js". In this case, you can find out "~~~~~~~~~.cache.js" no response with pushing key before you click log-in button.
Anyway, here is my way.
Reset your Network with following orders
you can insert these into cmd terminal as an admin mode.
netsh winsock reset
netsh int ip reset
Reboot
The IP information may be erased. So if you're using fixed IP address, fill the blanks with as-is IP address.
That's all.
You may follow this way to recover the connection.
Related
I'm using the ProtonVPN Linux CLI client Ubuntu 18.04.
I was previously using the 2.2.6 version, but I wanted to upgrade, which was a huge mistake.
I uninstalled v2.2.6 and followed the instructions for installing v3.7.1 on the ProtonVPN website.
After installation, I was able to create a connection, use the Internet, etc. Everything seemed to work. I enabled the killswitch permanently with $ protonvpn-cli ks --permanent.
Then, I closed my laptop lid. When I re-opened it, I had no Internet connection. I expected this, since that's how the 2.2.6 client worked, and I'm used to having to manually reconnect every time I open my laptop.
I attempted to reconnect to the VPN, but it didn't work the way I expected. $ protonvpn-cli r wouldn't find previous connection data, and $ protonvpn-cli c returned the error
Setting up ProtonVPN
An unknown error has occured. Please ensure that you have internet connectivity.
If the issue persists, please contact support
My wifi connection was fine. If connectivity is the issue, then I assume it must be the killswitch. I disabled the killswitch with $ protonvpn-cli ks --off. My first question is, under v.2.2.6 I did not have to disable the killswitch in order to connect to ProtonVPN itself. Is this changed in v3.7.1?
With the killswitch disabled, $ protonvpn-cli r continues to not find previous connection data, but $ protonvpn-cli c at least makes an attempt at working. However, it's still broken. It takes a minute to load the list of countries. When I select "United States", it seems to freeze while loading the list of servers. I've tried several times, and I've reconnected my wifi. It just won't load servers.
My device now lacks internet connectivity entirely. I've turned off the killswitch, I've closed the terminal I was running protonvpn-cli in, and there are no protonvpn processes active on the machine. The wifi is fine, and other devices are using it to connect to the Internet perfectly well. I've even rebooted the laptop, but it still won't connect to the internet. ProtonVPN has completely wrecked it.
Please help me.
Although I don't think the problem still persists on your side I've struggled with similar problem today. For me the solution found here https://askubuntu.com/questions/1319033/internet-stops-working-after-installing-protonvpn solved all connectivity issues, by simply removing the pvpn-ipv6leak-protection as following:
sudo nmcli connection delete pvpn-ipv6leak-protection
This is from proton's own old web page on how to remove the leftover "always on kill switch" uning command lines in the terminal. It is on the page: "How to install early-access Proton VPN Linux CLI"
located # https://protonvpn.com/support/linux-vpn-tool-early-access/
Disable the kill switch if you have uninstalled the app
The kill switch can be easily disabled from within the official Linux CLI app, but this will not be possible if you have uninstalled the CLI app first without disabling the kill switch. This may result in your system being unable to access the internet. To remove the kill switch after the CLI app has been uninstalled:
a) Identify Proton VPN connection names by running the command:
nmcli connection show --active
This will display a list of all your system’s active connections.
b) Look for any connections with the pvpn- prefix. This usually includes pvpn-killswitch and pvpn-ipv6leak-protection, and may include pvpn-routed-killswitch. Delete all these connections using the following command:
nmcli connection delete [connection name]
For example:
nmcli connection delete pvpn-killswitch
c) Re-run the following command to verify that Proton VPN connections have been deleted:
nmcli connection show --active
If any Proton VPN connections remain, delete them as described above.
Don't know enough about linux to be helpful but have run into the same issue.
Seems to be that proton stuffs with the resolv.conf file.
This link has a fix https://www.reddit.com/r/Ubuntu/comments/cpzaxo/remove_protonvpn_from_ubuntu/
But I can't get it to work as chattr will not allow me to remove the -i permissions.
chattr: Inappropriate ioctl for device while reading flags
Maybe it will work for you
I am a developer of ROS projects. Recently I am trying using ROS(melodic) on WSL2(Windows Subsystem for Linux), and all things works just great. But I got some trouble when I want to use another PC which also in the same local area network(LAN) to communicate with. Before setting the environment variables like "ROS_MASTER_URI, ROS_IP", I know that since WSL 2 work on Hyper-V so the IP show on WSL2 is not the one in the real LAN. I have to do some command like below in order to make everyone in LAN communicate with the specific host:PORT on WSL2.
netsh interface portproxy delete v4tov4 listenport=$port listenaddress=$addr
But here comes a new question:
The nodes which use TCPROS to communicate with each other have a random PORT every time I launch the file.
How can I handle this kind of problem?
Or is there any information on the internet that I can have a look?
Thank you.
The root problem is described in WSL issue #4150. To quote from that thread,
WSL 2 seems to NAT it's virtual network, instead of making it bridged
to the host NIC.
Option 1 - Port forwarding script on login
Note: From #kraego's comment (and the edited question, which I'm just seeing based on the comment), this is probably not a good option for ROS, since the port numbers are randomly assigned. This makes port forwarding something that would have to be dynamically done.
There are a number of workarounds described in that issue, for which you've already figured out the first part (the port forwarding). The primary technique seems to be to create a PowerShell script to detect the IP address and create the port forwarding rules that runs upon Windows login. This particular comment near the top of the thread seems to be the canonical go-to answer, although many people have posted their tweaks or alternatives throughout the very long thread.
One downside - I believe the script that is mentioned there needs to be run at logon since the WSL subsystem seems to only want to run when a user is logged in. I've found that attempting to run a WSL service or instance through Windows OpenSSH results in that instance/service shutting down soon after the SSH session is closed, unless the user is already logged into Windows with a WSL instance opened.
Option 2 - WSL1
I would also propose that, assuming it fits your workflow and if the ROS works on it (it may not, given the device access you need, but not sure), you can simply use WSL1 instead of WSL2 to avoid this. You can try this out by:
Backing up your existing distro (from PowerShell or cmd, use wsl --export <DistroName> <FileName>
Import the backup into a new WSL1 instance with wsl --import <NewDistroName> <InstallLocation> <FileNameOfBackup> --version 1
It's possible to simply change versions in place, but I tend to like to have a backup anyway before doing it, and as long as you are backing up, you may as well leave the original in place.
this is my situation: I usually run R from within Emacs using ESS into terminal emulator, in my local pc. In my work place we get a new server running R so I would use the remote server via ssh. I connect via ssh and all works well. What I would do is to keep alive the R console while I close my laptop and go home so, from my home I would reconnect to the existing R session.
I tried to put the R console in background using C-q C-z Enter to stop the process but, while I close the ssh connection the proces is killed. No luck using bg & too. I also tried mosh but, also in this case, I get some issue related to the UDP traffic across my work's network. Screen and tmux are not also very useful due to their bad interaction with the Emacs eshell.
In both client and server machine I run Debian 8 xfce.
Is there a way to keep alive the R terminal while closing the ssh connection? Which is your approach to the long R sessions?
EDIT
Finally here and here I found the solutio that I'm looking for. I tried the same approach as in the link above, but using tmux, and I get lots of error. The holy grail is screen. I tried to follow step-by-step that procedure but I get an error from emacs while I try to attach a screen session from within eshell. So I tried to use ansi-term instead of eshell and all works as expected. I can attach and detach the R session. In this way I use the remote server machine only for the computation while the R scripts are in my laptop.
So, this is the work-flow:
ssh to the host server
start screen session
start R
detach screen
exit from the server closing the ssh connection
run emacs as daemon in your local machine and open an emacsclient
instance (not necessary run emacs via emacsclient but I prefer this
way)
open your R script
open an ansi-term (M-x ansi-term)
ssh to the server from ansi-term
attach the screen session (screen -r)
connect the remote R console to the local R script (M-x ess-remote)
to detach from R from within ansi-term use Ctrl-q Ctrl-a d return
Thats it. Now I can run a remote R process using a local R script, closing the connection but leaving open the R console so I can re-attach to it in the future, also from a different IP.
This is one of my favourite topics :) Here is what I do:
Always start emacs as emacs --daemon so that it runs in the background.
Always launch emacsclient -nw (for textmode) or emacsclient -c (in x11/graphical mode) to access the daemonized emacs in the background. I have these aliased to emt and emx, respectively.
Now you are essentially done. You can ssh to that box and resume from whereever you can launch ssh from---which may be a smartphone or browser. And ESS of course allows you to have multiple R sessions. After M-x R I often invoke M-x rename-buffer to align the buffer with the project name or idea I work on.
I combine this further with both
byobu (which is a fancy tmux wrapper available in many distros and on OS X, and originally from Ubuntu) to have shell sessions persist
mosh for places like work and home where my laptop can simply resume
Strictly speaking you do not need byobu or mosh for emacs to persist (as running the daemon takes care of that) but you may want it for all your other shell session.
This setup has been my goto tools for years at work and home.
I have to construct the infrastructure so that multiple users can work on the same jupyter(ipython notebook) service, yet via different sessions, so the users can't interrupt each other.
I thought jupyterhub( https://github.com/jupyter/jupyterhub) is there to control everything, yet it still seems like the session is bound to one since if I logout of it on one window, an instance on another window also logs out.
Is there a way to control multi-sessions on jupyter?
Jupyter doesn't support multiple users editing the same notebook at the same time without data loss. I don't believe it is meant to. I believe Jupyter is meant to provide a relatively easy to configure and install instance of python that contains the same installed modules and environment to minimize problems caused by environmental differences between developer workstations.
Also, it's meant to make the barrier for entry to programming python and working in data science much lower than it otherwise would be. That is, it's much easier to talk an analyst into visiting a website than learning a new programming language.
More to the point of your question, though: The way Jupyter handles 'sessions' is that (unless configured otherwise), every Jupyter user corresponds to a user on the on the server that is running Jupyter and every time you log in to Jupyter you are effectively creating a new login to that server's operating system. It immediately follows that if you log out of Jupyter from one window, you're logging out of not just that browser's session, but also the login to the Jupyter server's operating system as well, which would kill all other open browser windows.
You question is a bit unclear, JupyterHub is meant to support multi-user across many machines. If course if you use the same browser from the same machine, you get logged out too, as the browser is carrying the connexion information that get revoked.
Jupyterhub is a web based multiuser application, that provides session and authentication services.
Jupyterhub will be hosted in unix/linux server, the client can access it using the ip address and port number,Once it is accessed by client, the client must enter the userid and password which is associated with the sytem users in server (PAM authentication) which will redirect to the home directory of the current user.
You can build a infrastructure by using jupyterhub, which is meant for multi-user. The jupyterhub just provides multi user interface and PAM authentication, you have to configure security, file access permission everything in kernel level using shell script.
Normally, you host a jupyterhub or jupyter notebook in command line. In the same way you can write a shell script to setup multi-user environment.
I have a long running job that I'd like to run using EC2 + RStudio. I setup the EC2 instance then setup RStudio as a page on my web browser. I need to physically move my laptop that I use to setup the connection and run the web browser throughout the course of the day and my job gets terminated in RStudio but the instance is still running on the EC2 dashboard.
Is there a way to keep a job running without maintaining an active connection?
Does it have to be started / controlled via RStudio?
If you make your task a "normal" R script, executed via Rscript or littler, then you can run them from the shell ... and get to
use old-school tools like nohup, batch or at to control running in the background
use tools like screen, tmux or byobu to maintain one or multiple sessions in which you launch the jobs, and connect / disconnect / reconnect at leisure.
RStudio Server works in similar ways but AFAICT limits you to a single user per user / machine -- which makes perfect sense for interactive work but is limiting if you have a need for multiple sessions.
FWIW, I like byobu with tmux a lot for this.
My original concern that it needed to maintain a live connection was incorrect. It turns out the error was from running out of memory, it just coincided with being disconnected from the internet connection.
An instance is started from the AWS dashboard and stopped or terminated from there also. As long as it is still running it can be accessed from an RStudio tab by copying the public DNS to the address bar on the web page and logging in again.