ERROR: can not send request; node process not running

[tomsseisums]

I installed TypeScript for Sublime for the first time and it worked like a charm. All of a sudden I am getting errors about node not running.

Excerpt from console:

spawning node module: C:\Users\psycketom\Desktop\ST3\Data\Packages\TypeScript\tsserver\tsserver.js
Found node executable at node
2015-06-15 16:48:25,048: 12592: ERROR: can not send request; node process not running

I just edited my preferences, to point to the exact node path. No success either:

spawning node module: C:\Users\psycketom\Desktop\ST3\Data\Packages\TypeScript\tsserver\tsserver.js
Found node executable at C:\Program Files\nodejs\node.exe
2015-06-15 16:58:35,129: 12448: ERROR: can not send request; node process not running

---

After numerous ST restarts, I found out that the problem is occasional.

And environment info: Windows 7 x64 node v0.12.3 Sublime Text 3, build 3083

---

What could be the problem?

[DeezCashews]

Getting the same thing here.

Windows 7 x64 node v0.12.4 Sublime Text 3, build 3083

[DanielRosenwasser]

How are you opening Sublime? Is node in your system's PATH variable?

[zhengbli]

Is it happening on the latest bit on master? Looks like it can find the node path correctly, but cannot start it for some reason.

[DeezCashews]

Yes node is on my path. I am starting sublime from D:\<somedir>\subl as sublime is on my path too. I can run node D:\sublime3\Data\Packages\TypeScript\tsserver\tsserver.js just fine from the command line also, but sublime3 was still giving the same errors in D:\sublime3\Data\Packages\TypeScript\TS.log.

[zhengbli]

@DeezCashews is the problem also occasional for you? And is your plugin installed from the package control or cloned from the repo?

[DeezCashews]

Installed from the PackageControl. I'm not sure if it's occasional or not right now. I had it fixed temporarily I think by tweaking env, but then broke it on purpose to figure out solution for @joltmode but now I can't seem to get working again so I guess it could be occasional.

[DeezCashews]

Ok, so I figured out WHAT is breaking it, but no idea why...

Executing D:\sublime3\subl.exe = errors above Executing D:\sublime3\sublime_text.exe = lovely code assist from tsserver.js :)

Note: The Windows installation provides a separate subl.exe, this is not a symlink to the usual executable as is often recommended as part of setup on *nix installs

I must have accidentally opened it with sublime_text.exe before with an Open With... from the Windows Shell before, I almost always use subl from the command line).

Can anyone try to repeat?

[DeezCashews]

@joltmode are you using subl.exe also? If so, try using sublime_text.exe instead and let us know what happens.

[zhengbli]

Interesting. I didn't know that subl.exe could be different from sublime_text.exe. I'll do more research on that.

[DeezCashews]

Well it's only 140k vs the 5.5M so it's not just a copy or anything, but yeah, no idea why. A complete shot in the dark would be it obviously has to execute the actual sublime_text.exe somehow, so perhaps it is then being executed with different privileges than the Windows user executing it directly. I just mention this because a lot of sublime plugins seem to write to temp directories which is often set to C:\Users\AppData\Local\Temp. While temp dirs might not have privelege issues, something else might (like say, requesting a port to listen on?).

Edit I think we'd have our answer quicker if an exception wasn't being swallowed HERE

[DeezCashews]

Well, more power to you guys for writing python because the last half hour figuring out proper indentation, simple exception handling, etc. was brutal for me, but I managed to learn a little and modified the code to get you this information:

Traceback (most recent call last):
  File "D:\sublime3\Data\Packages\TypeScript\libs\nodeclient.py", line 69, in __init__
    stdin=subprocess.PIPE, stdout=subprocess.PIPE,startupinfo=si)
  File "./subprocess.py", line 789, in __init__
  File "./subprocess.py", line 1026, in _get_handles
  File "./subprocess.py", line 1038, in _make_inheritable
OSError: [WinError 6] The handle is invalid

[zhengbli]

@DeezCashews Thanks for all the research! Looks like this is related http://www.sublimetext.com/forum/viewtopic.php?f=3&t=2464. Somebody else has this problem too (https://github.com/aponxi/sublime-better-coffeescript/issues/82), it seemed to be a path problem for them. I'm still looking.

[zhengbli]

Since I can't repro the problem on any of my machine, can you do a print(node_path) before line 69 in nodeclient.py to see if the path is right?

[DeezCashews]

Ahhh, interesting. One more set of tests given that info shows:

1. Both sublime_text.exe and subl.exe fail from the command line
2. Double clicking sublime_text.exe works but double clicking subl.exe still causes error
3. start sublime_text.exe works from command line but start subl.exe still causes error

And to answer your question: node_path is just "node" as assigned previously because os.name == "nt"

[DeezCashews]

I give up, my eyes are bleeding. For anyone else who comes across this, the workaround is to create a sublime.bat file with the following contents start C:\<pathto>\sublime_text.exe %* and just call sublime <args> instead of using subl.exe or sublime_text.exe from the command line.

[zhengbli]

The problem is that both subl.exe and sublime_text.exe works for me, either started from windows shell or command line. I'll find a win 7 VM tomorrow to try it on, it is indeed very strange issue.

[tomsseisums]

5 runs of subl.exe - 5/5 error. 5 runs of sublime_text.exe - 5/5 no problems. Some runs from a shortcut I've created and using st, that previously pointed to subl.exe and now points to sublime_text.exe - no problems.

Fun. :D

[DeezCashews]

@zhengbli Win 7 Pro x64 here FYI

[DanielRosenwasser]

@DeezCashews and @joltmode, this may sound like a joke, but it is a legitimate question: have you tried restarting your computer? I'm taking a shot in the dark, but there may be something about your PATH variable not being appropriately propagated.

[tomsseisums]

Ha, good point - no I haven't restarted.

Though, as I already edited in the first post, I added the correct node_path entry to my User.sublime-preferences - didn't change a thing. The sublime_text.exe instead of subl.exe is working flawlessly, though.

[DeezCashews]

@DanielRosenwasser Of course, "3 times, you always reboot it 3 times" - Chip (nsfw)

But yeah, no change.

[mcnameej]

I ran into this today and wasted a few hours on it. :cry:

I believe the root cause is the way Python implements subprocess.Popen(). It's a known issue; see https://bugs.python.org/issue3905. The problem was first reported in 2008 and has never been fixed.

The TypeScript plugin can work around the problem by always explicitly passing stdin, stdout, and stderr to subprocess.Popen(). Use subprocess.DEVNULL for the ones you don't need rather than leaving them unspecified.

diff --git a/typescript/libs/node_client.py b/typescript/libs/node_client.py
index 9abd8f4..fc5464b 100644
--- a/typescript/libs/node_client.py
+++ b/typescript/libs/node_client.py
@@ -80,7 +80,7 @@ class NodeCommClient(CommClient):
     def debug(self, file):
         # TODO: msg if already debugging
         self.debug_proc = subprocess.Popen(["node", "--debug", file],
-                                            stdin=subprocess.PIPE, stdout=subprocess.PIPE)
+                                            stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.DEVNULL)

     def sendCmd(self, cmd, cb, seq):
         """
@@ -262,11 +262,11 @@ class ServerClient(NodeCommClient):
                     si = subprocess.STARTUPINFO()
                     si.dwFlags |= subprocess.SW_HIDE | subprocess.STARTF_USESHOWWINDOW
                     self.server_proc = subprocess.Popen([node_path, script_path],
-                                                         stdin=subprocess.PIPE, stdout=subprocess.PIPE, startupinfo=si)
+                                                         stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.DEVNULL, startupinfo=si)
                 else:
                     log.debug("opening " + node_path + " " + script_path)
                     self.server_proc = subprocess.Popen([node_path, script_path],
-                                                         stdin=subprocess.PIPE, stdout=subprocess.PIPE)
+                                                         stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.DEVNULL)
             except:
                 self.server_proc = None
         # start reader thread
@@ -301,11 +301,11 @@ class WorkerClient(NodeCommClient):
             si = subprocess.STARTUPINFO()
             si.dwFlags |= subprocess.SW_HIDE | subprocess.STARTF_USESHOWWINDOW
             self.server_proc = subprocess.Popen(
-                [node_path, self.script_path], stdin=subprocess.PIPE, stdout=subprocess.PIPE, startupinfo=si
+                [node_path, self.script_path], stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.DEVNULL, startupinfo=si
             )
         else:
             self.server_proc = subprocess.Popen(
-                [node_path, self.script_path], stdin=subprocess.PIPE, stdout=subprocess.PIPE)
+                [node_path, self.script_path], stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.DEVNULL)

         # start reader thread
         if self.server_proc and (not self.server_proc.poll()):

[zhengbli]

@mcnameej Does this solve the problem for you? If so, a pull request is more than welcomed!

[mcnameej]

@zhengbli: The change appears to fix the problem, however I still see one "[WinError 6]" in the console. Not sure where it's coming from, and I've already spent more time on this than I should.

[OliverJAsh]

I am also getting this error on Mac, when I open the application from the system UI. If I open from my terminal, it's fine.

My path is set in ~/.zprofile, but when the TypeScript plugin loads, I see this in my console:

Unable to find executable file for node on path list: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:$NVM_BIN

TypeScript seems to be running before Sublime runs ~/.zprofile.

[Dynom]

Same problem as @OliverJAsh. Even when I set node_path in Preferences.sublime-settings.

I use NVM, and my path set following the $NVM_BIN approach. Not sure what .profile sublime reads, but it's not OSX's ~/.profile.

When I add the same lines to ~/.bashrc the following happens:

...
Found node executable at /usr/local/var/nvm/versions/node/v4.2.1/bin/
2015-11-09 17:30:15,293: 140735187030016: ERROR: can not send request; node process not running
2015-11-09 17:30:26,067: 140735187030016: ERROR: can not send request; node process not running
2015-11-09 17:32:09,962: 140735187030016: ERROR: can not send request; node process not running
2015-11-09 17:32:10,166: 140735187030016: ERROR: can not send request; node process not running
2015-11-09 17:32:10,171: 140735187030016: ERROR: can not send request; node process not running
2015-11-09 17:32:14,034: 140735187030016: ERROR: can not send request; node process not running
2015-11-09 17:32:14,237: 140735187030016: ERROR: can not send request; node process not running
2015-11-09 17:32:14,239: 140735187030016: ERROR: can not send request; node process not running
2015-11-09 17:32:14,240: 140735187030016: ERROR: can not send request; node process not running
2015-11-09 17:32:14,866: 140735187030016: ERROR: can not send request; node process not running
2015-11-09 17:32:14,867: 140735187030016: ERROR: can not send request; node process not running

These are the lines in my .bashrc:

cat ~/.bashrc
export NVM_DIR=$(brew --prefix)/var/nvm
source $(brew --prefix nvm)/nvm.sh
PATH="${PATH}:${NVM_BIN}"

I've applied the patch provider by @mcnameej, but that doesn't solve the problem.

[Dynom]

@zhengbli Is there anyone working on this?

[zhengbli]

@Dynom Yes we are working on all the issues based on priority, as right now the team doesn't have much resources that could fix everything in time. Sorry for the delay if it is causing you inconvenience, I'll take a look tomorrow.

[Dynom]

Much appreciated @zhengbli. For other people with the same problem, I've figured out a work-around that ended up to be quite easy:

I've specified the following path in my PROJECTNAME.sublime-project file:

"node_path": "${NVM_BIN}/node"

For completeness the other steps I've taken (I'm on OSX):

I've added the following lines to my ~/.bashrc

export NVM_DIR=$(brew --prefix)/var/nvm
source $(brew --prefix nvm)/nvm.sh
PATH="${PATH}:${NVM_BIN}"

And I've applied the patch by @mcnameej.

I'm not sure if all steps are required for it to work properly, but now I have the completion and features that I was looking for.

[zhengbli]

Hey @Dynom, this may sound dumb, but have you tried to set node_path to /usr/local/var/nvm/versions/node/v4.2.1/bin/node instead of /usr/local/var/nvm/versions/node/v4.2.1/bin/? Does that work? It seems to be working for me on my mac mini.

[zhengbli]

@OliverJAsh the plugin starts at the standard entry point provided by Sublime (the plugin_loaded callback), so there may not be much can be done to delay it even further. Can you try specifying node_path in your Preferences.sublime-settings as a work around? Set it to the path of node executable.

[zhengbli]

According to a stackoverflow answer, the environment variable the sublime has was affected by its parent process. On Unix the plugin doesn't explicitly read any profile file, it only calls os.environ["PATH"] to get the PATH variable (and two other known paths: /usr/local/bin as well as $NVM_BIN). Therefore it might be more stable to set a node_path explicitly if it is causing issues.

[Dynom]

Not sure if your reply was on my initial question or on my last question @zhengbli. Setting the node_path explicitly to the binary is exactly what I did for my work-around, which I specified in my last update.

In my initial reply, however, I pasted a log. One line reads Found node executable at /usr/local/var/nvm/versions/node/v4.2.1/bin/. Which is confusing, because it didn't actually found the executable, it merely concluded that a path was defined. The rest of the code, however, assumes that the same path is actually the path to the binary. So the message should instead be something like "configured path is .." and an additional check (isFile && isExecutable) should've concluded that it's actually not a path to an executable.

The best situation would obviously be that the binary is actually found :-)

I explicitly want to use $NVM_BIN, since I want my IDE to use the same binary I use system-wide and NVM is doing a fine job at managing versions. So I suppose my "work-around" can actually be seen as the reliable recommended approach?

[zhengbli]

@Dynom I was answering your initial question about why the plugin was broken. I was under the impression that setting the node executable directly didn't work for you, that you had to use NVM_BIN instead. The console message is indeed misleading, I'll fix it soon. On mac we search several common places where node executable normally is placed; and as sublime text may not run .profile, it is not guaranteed to be found it the node_path is set there. Although we did explicitly search NVM_BIN, maybe that's a bug if it doesn't work for you out of the box.

[zhengbli]

@Dynom I did notice you put an extra braces around the NVM_BIN, is that a mac convention? That's probably where the bug is.

[Dynom]

No it's not a Mac convention, it's (ba)sh shell-scripting convention. I use it to stay consistent for reasons like:

• ${foo}bar vs $foobar
• $1 vs $10 or ${1}0 vs ${10}
• ${array[0]} vs $array[0]
• ${path_to_file%.*}
• ${myname:=John Doe}

I'm not replying on the rest of your update, since I don't like to repeat myself.

[igl]

I have $NVM_BIN in the $PATH and also tried setting the node_path in the .sublime-project to "...nvm/versions/node/v5.1.0/bin" and "...nvm/versions/node/v5.1.0/bin/node" directly but nothing helps.

My console output after restarting sublime:

2015-12-01 23:25:32,841: 140735202857728: WARNING: TypeScript plugin initialized.
plugins loaded
spawning node module: /Users/richard/Library/Application Support/Sublime Text 3/Packages/TypeScript/tsserver/tsserver.js
test
None
Unable to find executable file for node on path list: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:$NVM_BIN
To specify the node executable file name, use the 'node_path' setting
2015-12-01 23:25:32,845: 140735202857728: ERROR: can not send request; node process not running
ref view not found
2015-12-01 23:25:32,846: 140735202857728: ERROR: sequence item 0: expected str instance, NoneType found
Package Control: Skipping automatic upgrade, last run at 2015-12-01 23:09:37, next run at 2015-12-02 00:09:37 or after
Packages/TypeScript/popup.html
2015-12-01 23:25:43,325: 140735202857728: ERROR: can not send request; node process not running
2015-12-01 23:25:43,528: 140735202857728: ERROR: can not send request; node process not running
2015-12-01 23:25:43,531: 140735202857728: ERROR: can not send request; node process not running
2015-12-01 23:25:44,462: 140735202857728: ERROR: can not send request; node process not running

Funny that tsserver actually starts and spits out compiled files. The plugin however still refuses to communicate with it.

Also using node_path to point at a node executable is kind of confusing since this variable is used by node for a different purpose (from the docs: If the NODE_PATH environment variable is set to a colon-delimited list of absolute paths, then Node.js will search those paths for modules)

Meh.

More info:

λ node -v
v5.1.0
λ tsc -v
message TS6029: Version 1.7.3
λ subl -v
Sublime Text Build 3095
λ sw_vers -productVersion
10.10.1

[Dynom]

Just to try the static approach, does something like this work for you @igl ?

File: ~/Library/Application Support/Sublime Text 3/Packages/User/Preferences.sublime-settings

{
    "node_path": "/usr/local/var/nvm/versions/node/v5.1.0/bin/node"
}

( and possibly other properties, but the one mentioned is the most important one )

[antonybudianto]

@Dynom approach worked, thank you

[igl]

@Dynom Yes, that worked. Thanks.

[spencerhakim]

The real issue here is that Python doesn't implicitly perform variable expansion. Quick demonstration:

>>> os.path.isfile('$NVM_BIN/node')
False
>>> os.path.isfile(os.path.expandvars('$NVM_BIN/node'))
True

At least it's an easy fix.

[Dynom]

Someone who knows their stuff, thanks @spencerhakim.

[OliverJAsh]

@spencerhakim With that change, could we fix this error?

[zhengbli]

@OliverJAsh @Dynom @spencerhakim I updated according to @spencerhakim 's comment. Can you guys give it a try? Thanks

[mcnameej]

@zhengbli: I think there are two separate problems here. AFAICT, the original problem reported by @joltmode, and also encountered by me, has nothing to do with environment variable expansion. The problem with $NVM_BIN may have similar symptoms, which is why it got discussed here, but has a totally different root cause. I don't think fixing the environment variable problem lets you close this issue (#235).

[gcnew]

$NVM_BIN might not be resolved in OSX because GUI applications are not "sourced" with ~/.bash_profile thus the corresponding env vars are not set. This behaviour is encountered when applications are started from Dock/Spotlight.

PS: More info & links: http://stackoverflow.com/questions/135688/setting-environment-variables-in-os-x

[gmy77]

ERROR: can not send request; node process not running

Same here, i receive this error any app-start-time.

[pospi]

This does look like a variable expansion issue is partially at fault, per @spencerhakim's comments above. I found that only a fully qualified, expanded path for the node_path setting worked- any variable interpolation or homedir ~ aliases prevented it from working.