You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would really appreciate it if you could resolve the issue I describe below ASAP (I need to be able to use rmate again to run programs for a project with a deadline)
I recently found rmate is no longer working on a remote server, and I thought it might be because of a cross-talk with Jupyter Lab another user is using (on his account, just to be clear. We are not sharing the same account). For instance, when doing "sudo lsof -i tcp:52698" and then killing PIDs that appear from it by "sudo kill -9 [PID]", his Jupyter Lab process got shut down. Now, I wasn't totally sure whether rmate is not working because of the potential cross-talk, but I decided to change the default port number for rmate, 52698 to see if it solves the problem. I first followed jsmedmar's suggestion in https://stackoverflow.com/questions/35343853/how-to-use-sublime-text-over-ssh-with-multiple-computers-in-same-server-using-rs, but it didn't work. And then, I followed the suggestion in "Port Forwarding" section of https://macromates.com/blog/2011/mate-and-rmate/ (with RMATE_PORT=52699 instead of 12345 to be consistent with jsmedmar's suggestion above, but I guess this is not an important detail), but it still didn't work. So, changed all the files I modified back to their original configurations, which are: Packages/User/rsub.sublime-settings (used in the first suggestion; since this file didn't exist before I deleted it), ~/.ssh/config(used in both the first and second suggestions), ~/.bashrc (used in the second suggestion) in my local computer, and ~/.bash_profile (used in the first suggestion), /etc/ssh/sshd_config (used in the second suggestion) in the server. But, still I got the following error message:
/usr/local/bin/rmate: connect: Connection refused
usr/local/bin/rmate: line 412: /dev/tcp/[my IP address xx.xx.xx.xxx]/52699: Connection refused
Unable to connect to TextMate on [my IP address xx.xx.xx.xxx]:52699
In particular, I don't understand why the port number in that error message is still 52699. I tried both "-R 52698:localhost:52698" in the ssh command and adding "RemoteForward 52698 localhost:52698" in ~/.ssh/config, but whatever I do, the port number in the error message was still 52699. Also, I remember when I got a similar error message before I tried the two suggestions above, I got "localhost" in place of [my IP address xx.xx.xx.xxx] in the error message (although I am not totally sure).
I've reinstalled rmate but I still get the exact same error message. My guess is that while trying the first and second suggestions above, I changed RMATE_HOST and RMATE_PORT environment variables explicitly on the server side and this might have made some permanent changes to them. But, at least when I echo those variables they did not return anything. Another guess is that creating a file called "sub.sublime-settings" in Packages/User directory of the local Sublime Text (as suggested by the first suggestion) might have had some affect, but this might be unlikely since when I use a different local computer to try rmate on the remote server, I get the exact same error message.
I looked into /usr/local/bin/rmate file, but I am not familiar with the shell script, and I couldn't figure out what's wrong. At least I could see that the error message I got depends on "$host" and "$port" variables and something must have gone wrong with them.
In any case, if you could give any suggestions to solve this issue and allow me to use rmate again, I would really appreciate that!
The text was updated successfully, but these errors were encountered:
The error message changed to:
/usr/local/bin/rmate: connect: Connection refused
usr/local/bin/rmate: line 412: /dev/tcp/[my IP address xx.xx.xx.xxx]/52658: Connection refused
Unable to connect to TextMate on [my IP address xx.xx.xx.xxx]:52658
probably because I explicitly set RMATE_PORT, but still I couldn't use rmate.
I finally figured it out. The main problem I think was that RMATE_HOST probably somehow got set to "auto" permanently while I was trying the second suggestion above. I think this sets RMATE_HOST to whatever IP address I am currently using for my local computer.
The solution was to add the following lines to ".bash_profile":
if ([[ -n "$SSH_CLIENT" ]] || [[ -n "$SSH_TTY" ]]); then
export RMATE_HOST=localhost
export RMATE_PORT=52698
fi
I think you can change the port number to whatever port number you want, but I haven't tried that.
Hi,
I would really appreciate it if you could resolve the issue I describe below ASAP (I need to be able to use rmate again to run programs for a project with a deadline)
I recently found rmate is no longer working on a remote server, and I thought it might be because of a cross-talk with Jupyter Lab another user is using (on his account, just to be clear. We are not sharing the same account). For instance, when doing "sudo lsof -i tcp:52698" and then killing PIDs that appear from it by "sudo kill -9 [PID]", his Jupyter Lab process got shut down. Now, I wasn't totally sure whether rmate is not working because of the potential cross-talk, but I decided to change the default port number for rmate, 52698 to see if it solves the problem. I first followed jsmedmar's suggestion in https://stackoverflow.com/questions/35343853/how-to-use-sublime-text-over-ssh-with-multiple-computers-in-same-server-using-rs, but it didn't work. And then, I followed the suggestion in "Port Forwarding" section of https://macromates.com/blog/2011/mate-and-rmate/ (with RMATE_PORT=52699 instead of 12345 to be consistent with jsmedmar's suggestion above, but I guess this is not an important detail), but it still didn't work. So, changed all the files I modified back to their original configurations, which are: Packages/User/rsub.sublime-settings (used in the first suggestion; since this file didn't exist before I deleted it), ~/.ssh/config(used in both the first and second suggestions), ~/.bashrc (used in the second suggestion) in my local computer, and ~/.bash_profile (used in the first suggestion), /etc/ssh/sshd_config (used in the second suggestion) in the server. But, still I got the following error message:
/usr/local/bin/rmate: connect: Connection refused
usr/local/bin/rmate: line 412: /dev/tcp/[my IP address xx.xx.xx.xxx]/52699: Connection refused
Unable to connect to TextMate on [my IP address xx.xx.xx.xxx]:52699
In particular, I don't understand why the port number in that error message is still 52699. I tried both "-R 52698:localhost:52698" in the ssh command and adding "RemoteForward 52698 localhost:52698" in ~/.ssh/config, but whatever I do, the port number in the error message was still 52699. Also, I remember when I got a similar error message before I tried the two suggestions above, I got "localhost" in place of [my IP address xx.xx.xx.xxx] in the error message (although I am not totally sure).
I've reinstalled rmate but I still get the exact same error message. My guess is that while trying the first and second suggestions above, I changed RMATE_HOST and RMATE_PORT environment variables explicitly on the server side and this might have made some permanent changes to them. But, at least when I echo those variables they did not return anything. Another guess is that creating a file called "sub.sublime-settings" in Packages/User directory of the local Sublime Text (as suggested by the first suggestion) might have had some affect, but this might be unlikely since when I use a different local computer to try rmate on the remote server, I get the exact same error message.
I looked into /usr/local/bin/rmate file, but I am not familiar with the shell script, and I couldn't figure out what's wrong. At least I could see that the error message I got depends on "$host" and "$port" variables and something must have gone wrong with them.
In any case, if you could give any suggestions to solve this issue and allow me to use rmate again, I would really appreciate that!
The text was updated successfully, but these errors were encountered: