Rubymine debug session crashing with vagrant ubuntu on windows 10


I'm running RubyMine 2017.3 on Win10, virtualbox vagrant with ubuntu.  When I'm running the server (debug mode), periodically the server will crash.  This happens annoyningly often and seems to be driven moodiness of rubymine or vagrant or something.  I wont see it for weeks, then I'll see it every 30 min or so.  

In the rubymine console window I will see:

Process finished with exit code -1

The next client web browser access will fail with "empty response from server", and subsequent requests will get connection refused.

Doing a ps -ef | grep ruby will show a zombie ruby-debug-ide process, which I must kill (otherwise restarting rubymine debug will show server already running)

Once that's done, I can restart the server from rubymine and after the painfully long server startup, I'm going again.  But it's really annoying.

Logs and Info

My vagrant file is here:

the only unusual thing is I have an explicit private network. (

Rubymine logs are below.  Not sure what's causing the 'processWillTerminate', but it's having problems with remote port forwarding removal.  FWIW I dont really need the remote port forwarding as I am using an explict private network to connect via browser to my app.  If there is a way to dsable RPF, and that's the problem, LMK)

Rubymine logs show the following

2017-12-30 00:08:13,652 [198983224] INFO - emote.RubyRemoteProcessHandler - processWillTerminate: removing port forwarding - Port forwarding[from remote server to local localhost:3000]
2017-12-30 00:08:13,652 [198983224] INFO - emote.RubyRemoteProcessHandler - Unable to remove port forwarding
com.intellij.remote.RemoteSdkException: Failed to delete local port forwarding
at com.intellij.ssh.process.SshProcess.removeLocalTunnel(
at org.jetbrains.plugins.ruby.remote.RubyRemoteProcessHandler.removeTunnels(
at org.jetbrains.plugins.ruby.remote.RubyRemoteProcessHandler.access$000(
at org.jetbrains.plugins.ruby.remote.RubyRemoteProcessHandler$1.processWillTerminate(
at sun.reflect.GeneratedMethodAccessor100.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
at java.lang.reflect.Method.invoke(
at com.intellij.execution.process.ProcessHandler$5.invoke(
at com.sun.proxy.$Proxy17.processWillTerminate(Unknown Source)
at com.intellij.execution.process.ProcessHandler.fireProcessWillTerminate(
at com.intellij.execution.process.ProcessHandler.access$200(
at com.intellij.execution.process.ProcessHandler$
at com.intellij.execution.process.ProcessHandler$TasksRunner.execute(
at com.intellij.execution.process.ProcessHandler.notifyTerminated(
at com.intellij.execution.process.ProcessHandler.notifyProcessTerminated(
at com.intellij.remote.BaseRemoteProcessHandler.onOSProcessTerminated(
at com.intellij.remote.BaseRemoteProcessHandler$1.a(
at com.intellij.execution.process.ProcessWaitFor$
at java.util.concurrent.Executors$
at java.util.concurrent.ThreadPoolExecutor.runWorker(
at java.util.concurrent.ThreadPoolExecutor$
Caused by: com.intellij.ssh.SshTransportException: Failed to delete local port forwarding
at com.intellij.ssh.SshSession.removeLocalTunnel(SshSession.kt:66)
at com.intellij.ssh.process.SshProcess.removeLocalTunnel(
... 22 more


Hello Josh,

sorry for the delay. Just to be sure, how have you added the remote SDK? Via Vagrant configuration or via SSH? Do you manage to run the app (not to debug)?



It is a vagrant remote sdk.

The failure is intermittent while it is running.  Starting it always works.  It will run for a while, and then have the crash.

The app itself will run just find on the linux command line with rails s

I'm not sure if the problem occurs when running not debugging in rubymine.


Hello Josh,

I've trie running debug with Vagrant based ruby SDK (in my case it was ubuntu/trusty64 box, rvm, ruby 2.4.1) on Windows 7 and it worked fine. I didn't manage to set up SDK with your box because it cannot be found. Does it crash on all the Rails applications or only a certain one? Are there any steps for stable reproduce?


Im using ruby 2.3.1, my box isnt published but it is based on trusty64

I have two rails apps on the box, and ive mostly seen it with the bigger of the two.(much bigger)

Lately Ive been just running the app from the command line, rails s...., to avoid the problem,

Ill switch back to running it debug in rubymine and see if i can narrow it down

What do those error messages in the logs surrounding the failure actually mean?  What causes them?

that would be helpful in narrowing it


I have the exact same problem.  Only, it doesn't matter if I and running in debug or not.  Either way I get the same error and need to manually kill the process in the Ubuntu vagrant before I can restart rails.  Sometimes I can run all day with a problem.  Other times it fails within 5 minutes.  I haven't found any pattern to when it actually dies.

Did you ever come up with a solution for this issue?


Thank you for confirming that I am not crazy. :)

I'm not aware of any solution. I've been trying to figure out what causes it to reproduce, but have not.

The only workaround I've found is to start the server manually on ubuntu, eg rails s -b

This only helps in "run" mode not "debug" mode.  That's become my usual way of starting the server, except when I need to debug and take my chances with the IDE.

What host operating system, virtualization engine, and synced folders method are you using?

I'm on Win10x64 with VirtualBox, with vritualbox shared folders




I have the same environment as you: Win10x64 with VirtualBox, with VirtualBox shared folders.



@olga How does rubymine detect that it should call this, or the server is terminating?

Remote.RubyRemoteProcessHandler - processWillTerminate: removing port forwarding - Port forwarding[from remote server to local localhost:3000] 

Is it checking for the existence of a file, lock or other related filesystem element?

or is it checking for network connectivity via a tcp socket or something?


I've wondered if it is file or network related.  It might be useful to try a different sync'd folders mechanism.

I had tried to use SMB back in the day, but vagrant SMB annoyingly required Admin privileges, which meant Rubymine needed to run as Admin, which was laughable non-starter.

But I see this issue has been fixed in recent versions of Vagrant. 

See this Github issue:

See this pull request;

Would you give using the updated SMB support a try and see if the problem still repos?

(I"m on the road for a while and not intensely coding right now, but still want to see this fixed)


I believe we tried using SMB a while back as well.  I'm working on multiple project and probably won't have time to mess around with SMB for some time...


Understood.  I've been subsisting with running the server on the command line 'rails s....' which reduces the pain.  We can also choose, in the interim, to write code without bugs so we don't need the debugger.

@olga / JetBrains: Reconfiguring my vagrant to SMB file sync a pretty big work item. Can you shed some light on how rubymine detects that it should call this, or that the server is terminating? Is it possibly filesystem related?

Remote.RubyRemoteProcessHandler - processWillTerminate: removing port forwarding - Port forwarding[from remote server to local localhost:3000] 

Is it checking for the existence of a file, lock or other related filesystem element?

or is it checking for network connectivity via a tcp socket or something?



@Josh, the stacktrace you've mentioned is more about the ports' cleaning when the app has already crashed. Could you please check the last 2018.2.2 EAP version? If the problem persists please turn the verbose debugger's output on (Settings | Build, Execution, Deployment | Debugger | Verbose debugger output), launch debug process and attach the output.


Please sign in to leave a comment.