platformio
Could not start PIO Home server: Error: connect EACCES 127.0.0.1:8010
Temporary solution
- Open VSCode settings https://docs.platformio.org/en/latest/integration/ide/vscode.html#settings
- Search for
pio home port - Set
platformio-ide.pioHomeServerHttpPortto9013 - Restart VSCode.
%23 Description of problem ALready tried to re-install VS Code, delete folder 'platformio.platformio-ide-2.3.3' in extensions folder an re-install the platformIO extension.
BEFORE SUBMITTING, PLEASE SEARCH FOR DUPLICATES IN
- https://github.com/platformio/platformio-vscode-ide/issues%3Fq=is%3Aissue
%23 Configuration
VSCode: 1.59.0 PIO IDE: v2.3.3 System: Windows_NT, 10.0.19043, x64
%23 Exception
Error: Could not start PIO Home server: Error: connect EACCES 127.0.0.1:8010
at c:\Users\chris\.vscode\extensions\platformio.platformio-ide-2.3.3\node_modules\platformio-node-helpers\dist\index.js:1:5946
at processTicksAndRejections (internal/process/task_queues.js:93:5)
i have the same issue,
stack trace: RequestError: connect ECONNREFUSED 127.0.0.1:8027 at ClientRequest.<anonymous> (c:\Users\void\.vscode\extensions\platformio.platformio-ide-2.3.3\node_modules\got\dist\source\core\index.js:956:111) at Object.onceWrapper (events.js:422:26) at ClientRequest.emit (events.js:327:22) at ClientRequest.EventEmitter.emit (domain.js:467:12) at ClientRequest.origin.emit (c:\Users\void\.vscode\extensions\platformio.platformio-ide-2.3.3\node_modules\@szmarczak\http-timer\dist\source\index.js:39:20) at Socket.socketErrorListener (_http_client.js:469:9) at Socket.emit (events.js:315:20) at Socket.EventEmitter.emit (domain.js:467:12) at emitErrorNT (internal/streams/destroy.js:106:8) at emitErrorCloseNT (internal/streams/destroy.js:74:3) at processTicksAndRejections (internal/process/task_queues.js:80:21) at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1146:16)
S @ workbench.desktop.main.js:sourcemap:62
workbench.desktop.main.js:sourcemap:2038 [[object Object]]connect ECONNREFUSED 127.0.0.1:8027
$onExtensionRuntimeError @ workbench.desktop.main.js:sourcemap:2038
workbench.desktop.main.js:sourcemap:2038 RequestError: connect ECONNREFUSED 127.0.0.1:8027
at ClientRequest.<anonymous> (c:\Users\void\.vscode\extensions\platformio.platformio-ide-2.3.3\node_modules\got\dist\source\core\index.js:956:111)
at Object.onceWrapper (events.js:422:26)
at ClientRequest.emit (events.js:327:22)
at ClientRequest.EventEmitter.emit (domain.js:467:12)
at ClientRequest.origin.emit (c:\Users\void\.vscode\extensions\platformio.platformio-ide-2.3.3\node_modules\@szmarczak\http-timer\dist\source\index.js:39:20)
at Socket.socketErrorListener (_http_client.js:469:9)
at Socket.emit (events.js:315:20)
at Socket.EventEmitter.emit (domain.js:467:12)
at emitErrorNT (internal/streams/destroy.js:106:8)
at emitErrorCloseNT (internal/streams/destroy.js:74:3)
at processTicksAndRejections (internal/process/task_queues.js:80:21)
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1146:16)
$onExtensionRuntimeError @ workbench.desktop.main.js:sourcemap:2038
SOLUTION!
This appears to be root-caused to the same underlying issue reported in https://github.com/docker/for-win/issues/3171#issuecomment-554587817 (... but it's NOT a docker specific issue!)
Really short summary of how combination of issues may cause this....
If 3171 turns out to be the same cause, then this issue is caused by a combination of Hyper-V (specifically Hyper-V Networking Service aka HNS) reserving a LOT of dynamic ports, coupled with something that sets the starting port number for dynamic TCP allocations to 1024. (unclear who culprit is ... docker? windows update? many? other?)
First, it's perfectly valid for HNS to reserve a bunch of dynamic ports. The problem is, when they could include values that are used by other programs that expect a fixed port. Thus, because HNS might reserve a different subset of TCP ports at each and every boot, it will cause random-looking failures. Debugging is very hard because most utilities won't show that anything is actually using those ports, but attempting to bind to them will still fail.
If you have Hyper-V enabled, then this can make the problem more obvious, but only because Hyper-V has a service that uses a lot of dynamic ports. Any program that uses dynamically bound TCP ports can cause sporadic failures.
How to know if you are affected by this issue?
Simply review the output of the following three commands ... neither of which requires administrative privileges:
netsh int ipv4 show dynamicport udp
netsh int ipv4 show dynamicport tcp
netsh int ipv4 show excludedportrange tcp
You're likely affected if the following are true:
- The first command (dynamicport UDP) shows a start port of 49152
- The second command (dynamicport TCP) shows a start port of 1024
- The third command (excludedportrange TCP) shows a long list of excluded ports
My example output, showing I'm affected
Here's the output from the relevant commands on my machine:
C:\Q>netsh int ipv4 show dynamicport tcp
Protocol tcp Dynamic Port Range
---------------------------------
Start Port : 1024
Number of Ports : 64511
C:\Q\>netsh int ipv4 show dynamicport udp
Protocol udp Dynamic Port Range
---------------------------------
Start Port : 49152
Number of Ports : 16384
As is clear, the starting port # for dynamically allocated TCP ports was set to start at 1024. It appears that Windows updated the UDP settings to a reasonable range, but failed to update the TCP settings.
Minimal fix
Running the following (from an administrator/elevated cmd.exe) to update the starting port number for dynamically allocated TCP ports:
netsh int ipv4 set dynamic tcp start=49152 num=16384
Reboot the machine. Breathe a sigh of relief as all your random network failures resolve?
If you hit this problem, please confirm the above can fix the issue for you also?
SOLVED
See comment below: https://github.com/platformio/platformio-vscode-ide/issues/2667#issuecomment-976142717
Old post
I'm still hitting this. I understand this can be difficult to diagnose remotely. I'd love hints on how to do so.
From black-box testing:
- cmd-line invocation of
pio homeloads the web page, which reportsERR_CONNECTION_REFUSEDa. after reboot,pio homeappears to start the server... b. after running once (either cmd-line or failing to open page in VSCode), reportsPlatformIO Home server is already started in another process - However, access to
https://127.0.0.1:8008(the configured PIO Home port) returnsECONNREFUSED - Attempts to access
https://127.0.0.1:31524(random port with nothing) gets the sameECONNREFUSED
Based on the above, I can't tell if the PIO Home server is actually non-responsive, or if something if interfering with the connection, which would be my first step at diagnosis.
Is there a way to cause the PIO Home server to be periodically logging a "keepalive" type message to a log somewhere, just to verify it's alive and well?
This issue has been automatically marked as stale because it has not had recent activity. Please provide more details or it will be closed if no further activity occurs. Thank you for your contributions.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
SOLVED
See comment below: https://github.com/platformio/platformio-vscode-ide/issues/2667#issuecomment-976142717
Old post
It appears that PIO folks don't review questions asking how to get data to enable tracing the root cause of issues. That makes me sad, while I simultaneously understand the problem of high-volume feedback.
For me, this eventually resolved itself after many weeks. I have no idea why. I really don't like not knowing the root cause, because that means when it occurs again, I will again be stuck with no way forward.
PIO folk ... if you have any data that you want collected (or would be helpful to collect) when this occurs, PLEASE post here. I'm not the only one this happens to, and it prevents use of PIO entirely when it does happen. Else, I won't update again next time this goes stale.
Could someone provide us with a remote session to debug this issue? Please email to [email protected] for details.
After a time of not occurring, it is happening again. I've reached out to Ivan Kravets to see how to enable further debugging.
Some (potentially) useful information:
I'm on Windows 10. The TCP port that PIO Home was attempting to run on was port 8080.
However, Windows may have reserved that port for some other program? (not entirely sure about this part...)
See output of the following command (from a cmd.exe terminal):
netsh int ipv4 show excludedportrange tcp
I my case, ports 7981 8080 were listed. I was able to workaround the issue (at least temporarily) by manually setting the port used by PIO Home to a number that was not listed in the ranges from the above command. In my case, I used port 11011.
Still seeing if there is anything more I can do to help root-cause more deeply, hopefully with the goal of preventing this silent, non-actionable error from affecting other users....
SUCCESS!
This appears to be root-caused to the same underlying issue reported in https://github.com/docker/for-win/issues/3171#issuecomment-554587817 (... but it's NOT a docker specific issue!)
Really short summary of how combination of issues may cause this....
If 3171 turns out to be the same cause, then this issue is caused by a combination of Hyper-V (specifically Hyper-V Networking Service aka HNS) reserving a LOT of dynamic ports, coupled with something that sets the starting port number for dynamic TCP allocations to 1024. (unclear who culprit is ... docker? windows update? many? other?)
First, it's perfectly valid for HNS to reserve a bunch of dynamic ports. The problem is, when they could include values that are used by other programs that expect a fixed port. Thus, because HNS might reserve a different subset of TCP ports at each and every boot, it will cause random-looking failures. Debugging is very hard because most utilities won't show that anything is actually using those ports, but attempting to bind to them will still fail.
If you have Hyper-V enabled, then this can make the problem more obvious, but only because Hyper-V has a service that uses a lot of dynamic ports. Any program that uses dynamically bound TCP ports can cause sporadic failures.
How to know if you are affected by this issue?
Simply review the output of the following three commands ... neither of which requires administrative privileges:
netsh int ipv4 show dynamicport udp
netsh int ipv4 show dynamicport tcp
netsh int ipv4 show excludedportrange tcp
You're likely affected if the following are true:
- The first command (dynamicport UDP) shows a start port of 49152
- The second command (dynamicport TCP) shows a start port of 1024
- The third command (excludedportrange TCP) shows a long list of excluded ports
My example output, showing I'm affected
Here's the output from the relevant commands on my machine:
C:\Q>netsh int ipv4 show dynamicport tcp
Protocol tcp Dynamic Port Range
---------------------------------
Start Port : 1024
Number of Ports : 64511
C:\Q\>netsh int ipv4 show dynamicport udp
Protocol udp Dynamic Port Range
---------------------------------
Start Port : 49152
Number of Ports : 16384
As is clear, the starting port # for dynamically allocated TCP ports was set to start at 1024. It appears that Windows updated the UDP settings to a reasonable range, but failed to update the TCP settings.
Minimal fix
Running the following (from an administrator/elevated cmd.exe) to update the starting port number for dynamically allocated TCP ports:
netsh int ipv4 set dynamic tcp start=49152 num=16384
Reboot the machine. Breathe a sigh of relief as all your random network failures resolve?
If you hit this problem, please confirm the above can fix the issue for you also?
@ivankravets ... I think I found the root cause.
Can you detect if the dynamic TCP start port is 1024, and if so, provide a useful error message on how a person can fix this themselves?