IPFS Desktop stuck on "IPFS is Starting" #1723

jjv360 · 2020-12-29T11:27:27Z

It never gets past IPFS is Starting for me, unless I run ipfs daemon in a terminal window first...

This error also happens when pressing Check for Updates, while in this "IPFS is Starting" stuck state...

Specifications

OS: win32
IPFS Desktop Version: 0.13.2
Electron Version: 9.3.2
Chrome Version: 83.0.4103.122

Error

TypeError: ctx.manualCheckForUpdates is not a function
    at click (C:\Users\jjv36\AppData\Local\Programs\IPFS Desktop\resources\app.asar\src\tray.js:198:30)
    at MenuItem.click (electron/js2c/browser_init.js:65:1624)
    at Function.executeCommand (electron/js2c/browser_init.js:73:1102)

The text was updated successfully, but these errors were encountered:

jessicaschilling · 2020-12-29T15:06:33Z

Thank you for reporting this. The core team is temporarily in a minimal state due to winter holidays but will add to triage upon return - in the meantime you may also wish to repost to https://discuss.ipfs.io/ for community support.

Question: Did you originally install Desktop for all users of this machine? Are you running as a different user than the one that installed Desktop?

jjv360 · 2020-12-29T19:53:14Z

Question: Did you originally install Desktop for all users of this machine? Are you running as a different user than the one that installed Desktop?

I installed it via chocolatey, so I'm not sure if it's installed for all users or not... My machine only has one user on it though.

jessicaschilling · 2021-01-04T19:06:30Z

@rafaelramalho19 - are you able to investigate further on your Windows machine? Thank you.

rafaelramalho19 · 2021-01-11T19:41:43Z

@jjv360 I installed ipfs-desktop through chocolatey and it works fine, I tried multiple aways to downgrade and upgrade to try and reproduce your error but I'm unable to.

Would you mind trying a fresh install of ipfs-desktop and see if that helps?

NorseGaud · 2021-01-14T21:51:20Z

Having this happen on macOS using brew install --cask ipfs : 0.13.2

NorseGaud · 2021-01-14T21:54:20Z

Confirmed it's also the case with the DMG installer.

lidel · 2021-01-14T22:03:44Z

@jjv360 @NorseGaud sadly we are unable to reproduce, need more information.

Did you do any of below by any chance?

Set custom IPFS_PATH anywhere?
Moved your repo to different location than the default?

If possible:

From the "IPFS icon" menu in your menubar/system tray, go to Advanced → Open Logs Directory
Find *.log files
Attach error.log and combined.log to this issue.

lidel · 2021-01-14T22:22:47Z

Sadly Desktop logs did not help.

@NorseGaud Are you able to Quit IPFS Desktop and then start it in terminal, to see if there is any output from go-ipfs daemon that does not end up in logs? I suspect there is an issue related to daemon startup.

Not sure how to do it (not a macOS user), perhaps something like:

open -a IPFS\ Desktop

You should see startup + then logs from go-ipfs similar to this:

2021-01-14T22:20:36.516Z info: [meta] logs can be found on /home/lidel/.config/IPFS Desktop
2021-01-14T22:20:37.479Z info: [web ui] window ready
2021-01-14T22:20:37.479Z info: [web ui] navigate to /
2021-01-14T22:20:37.499Z info: [tray] starting
2021-01-14T22:20:37.566Z info: [tray] started
2021-01-14T22:20:37.567Z info: [ipfsd] start daemon STARTED
2021-01-14T22:20:37.806Z error: [ipfsd] start daemon Error: Initializing daemon...
go-ipfs version: 0.7.0
Repo version: 10
System version: amd64/linux
Golang version: go1.14.4
(→ interesting stuff  here)

NorseGaud · 2021-01-15T14:22:02Z

Moving my comments to #1730

jessicaschilling · 2021-01-19T23:22:54Z

@jjv360 - per @rafaelramalho19's comment above, would you mind trying a fresh install of ipfs-desktop and see if that helps?

jessicaschilling · 2021-01-19T23:41:54Z

Note that #1734 is a duplicate error under Windows.

jjv360 · 2021-01-22T07:20:11Z

Sorry for the delay! I have uninstalled ipfs-desktop via chocolatey and installed 0.13.2, 0.13.1, 0.13.0 versions manually and they all get stuck the same way. I don't have a IPFS_PATH environment variable set. I deleted the logs and then started the app again, and when it got stuck error.log was empty, and combined.log showed this:

2021-01-22T07:14:41.405Z info: [meta] logs can be found on C:\Users\jjv36\AppData\Roaming\IPFS Desktop
2021-01-22T07:14:42.037Z info: [web ui] window ready
2021-01-22T07:14:42.037Z info: [tray] starting
2021-01-22T07:14:42.134Z info: [tray] started
2021-01-22T07:14:42.134Z info: [ipfsd] start daemon STARTED

Pressing "Check for Updates" still crashes with that ctx.manualCheckForUpdates is not a function error as well.

rafaelramalho19 · 2021-01-22T13:46:24Z

The Pressing "Check for Updates" still crashes with that ctx.manualCheckForUpdates is not a function error as well. part sounds especially weird, since I'm able to click the button in both my windows machines without any errors.

Also looking at the codebase there shouldn't really be an issue with the manual check for updates...

Are you able to provide us with your configuration file?

And also check your version in system tray to be 100% sure you're running ipfs-desktop@0.13.2 ?

jjv360 · 2021-01-23T07:59:27Z

I've tried the same install process (via chocolatey) on a virtual machine and it worked fine, so it's definitely something wrong on my machine only...

However I did notice that if you click Check for Updates during the 5 or so seconds that "IPFS is Starting" you do get the same crash.

Is there a way to see the full commandline to ipfs.exe that IPFS Desktop is trying to run? Then I can try run it manually... I don't even see ipfs.exe in task manager while it's in this state. I tried running this but it worked fine:

"C:\Users\jjv36\AppData\Local\Programs\IPFS Desktop\resources\app.asar.unpacked\node_modules\go-ipfs\go-ipfs\ipfs.exe" daemon --migrate --enable-gc --routing dhtclient

Here's my versions:

And here's my config (which I haven't changed):

{
	"ipfsConfig": {
		"type": "go",
		"path": "C:\\Users\\jjv36\\.ipfs",
		"flags": [
			"--migrate",
			"--enable-gc",
			"--routing",
			"dhtclient"
		],
		"keysize": 2048
	},
	"language": "en-US",
	"experiments": {
		"npmOnIpfs": false
	},
	"__internal__": {
		"migrations": {
			"version": "6.0.0"
		}
	},
	"openWebUIAtLaunch": false,
	"daemonConfigRevision": 1,
	"checkedCorsConfig": true,
	"window": {
		"width": 1441,
		"height": 901
	},
	"ipfsOnPath": false
}

jjv360 · 2021-01-23T08:07:51Z

I just noticed ipfsOnPath was false on my own machine but true on the virtual machine... I changed it to true on my own machine but it made no difference...

UnKnoWn-Consortium · 2021-01-23T13:39:49Z

I have encountered the same issue. The desktop app stuck at the starting loop unless I manually start an IPFS daemon at CLI. It appears the desktop app fails to invoke and spawn an ipfs.exe process.

I have cloned the repo and tried to see if the app has failed to locate the binary. The answer is negative. The app does successfully locate the bundled binary. My current bet is that the ipfsd-ctl package somehow fails to spawn the daemon at my system. Still investigating.

P.S. My affected system is Windows 10 Pro 64bit 20H2 19042.746.

UnKnoWn-Consortium · 2021-01-23T13:46:45Z

The Pressing "Check for Updates" still crashes with that ctx.manualCheckForUpdates is not a function error as well. part sounds especially weird, since I'm able to click the button in both my windows machines without any errors.

Also looking at the codebase there shouldn't really be an issue with the manual check for updates...

https://github.com/ipfs-shipyard/ipfs-desktop/blob/6dbfa13bfa0f80c490696818bbb5c4c42aeb22fe/src/index.js#L72
https://github.com/ipfs-shipyard/ipfs-desktop/blob/6dbfa13bfa0f80c490696818bbb5c4c42aeb22fe/src/index.js#L73

The startup process is stuck at the setupDaemon right before setupAutoUpdater. The function setupAutoUpdater is exactly where manualCheckForUpdates is defined. So I guess it is not that weird.

UnKnoWn-Consortium · 2021-01-23T19:20:08Z

Okay further investigation suggests it is a rather complicated matters as there are a couple of things interleaving with each other...

Before the start method of the ipfsd-ctl controller instance is called, a checkPorts function is called to determine if the ports required by ipfs are available.

https://github.com/ipfs-shipyard/ipfs-desktop/blob/6dbfa13bfa0f80c490696818bbb5c4c42aeb22fe/src/daemon/daemon.js#L72-L75

Things was first stuck at this checkPorts function defined at config.js.

https://github.com/ipfs-shipyard/ipfs-desktop/blob/6dbfa13bfa0f80c490696818bbb5c4c42aeb22fe/src/daemon/config.js#L216-L231

The culprit is the checkIfAddrIsDaemon function. What it does is to make a POST request to the previously identified API address (which is usually 127.0.0.1:5001) with a specific path /api/v0/refs?arg=/ipfs/QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn and see if there is a daemon already running that would reply with 200. Simple but not so elegant.

https://github.com/ipfs-shipyard/ipfs-desktop/blob/6dbfa13bfa0f80c490696818bbb5c4c42aeb22fe/src/daemon/config.js#L156-L175

The request has no timeout explicitly set. There is supposed to be a default timeout value of 120,000ms (i.e. 2 minutes) in Node 12.14.1 that comes with Electron 9 where the request can resort to (P.S. This default value was dropped in Node 13. So it is no longer the case in Electron 10 which comes with Node 14. See: nodejs/node#27558).

If there happens to be any service other than ipfs that listens to the API port (5001) but not replying to the request (properly a la HTTP). It should take the whole 2 minutes before the request timing out. But in my case the promise never gets resolved. The startup process is stuck there.

So I tried to get this fixed by adding back the timeout property at the request option and the listener for timeout event. But this is not the end. Continue next.

UnKnoWn-Consortium · 2021-01-23T20:11:59Z

Okay. Now, with the checkIfAddrIsDaemon finally resolving, the program proceeds and it determines that my setup needs an alternative port and offers me 5002 in the following prompt which is the expected behavior.

I clicked the "Use port 5002 instead". But the app is still stuck at the startup process. So our journey continues...

This time the program is stuck at the start method of the ipfsd-ctl controller.

https://github.com/ipfs/js-ipfsd-ctl/blob/85229f5b5f8e2d3c2676ca2ceb77cb4163627a6d/src/ipfsd-daemon.js#L181-L188

The method first invokes a checkForRunningApi function which is essentially a fs.readFileSync of the file api in the .ipfs folder. The file contains only one line and in my case it is "/ip4/127.0.0.1/tcp/5001". As the file is not empty, the method continues and calls two "private" methods _setApi and _createApi. This is the second culprit of the issue. I have accepted the alternative port (from 5001 to 5002) above but the file from which the ipfsd-ctl controller reads the api is not updated. Once I change the line in the api file to "/ip4/127.0.0.1/tcp/5002", Everything works.

I am not exactly sure about the lifecycle of this api file inside .ipfs folder. But this summarizes my situation. Hope it helps.

UnKnoWn-Consortium · 2021-01-23T20:21:18Z

@jjv360 I think you can try checking if the port 5001 is occupied by other application. If yes, maybe you can try changing the config and api file in .ipfs folder at your home folder and see if it works. Good luck.

jjv360 · 2021-01-24T10:22:00Z

@jjv360 I think you can try checking if the port 5001 is occupied by other application. If yes, maybe you can try changing the config and api file in .ipfs folder at your home folder and see if it works. Good luck.

Yes, thank you so much! I have AirServer running which also uses port 5001, if I close that then IPFS Desktop starts without any issues. I changed those files to port 5005 and now I can run both apps at the same time as well.

I did have to change IPFS Companion's settings to that port as well (the Chrome extension) but it seems to be working fine...

jessicaschilling · 2021-01-25T15:27:03Z

@UnKnoWn-Consortium Thanks for stepping in here. Will close this issue, but feel free to re-open if necessary.

UnKnoWn-Consortium · 2021-01-25T19:14:00Z

@jessicaschilling I think you had better take a look at the two issues I identified. Otherwise they will keep coming back and haunt other users. They are specifically:

Promise returned by checkIfAddrIsDaemon function at config.js does not resolve when the target address is occupied by another service that may or may not be responding to the test POST request; and
Selecting an alternative port via the prompt presented by the app does not alter the api file inside the .ipfs folder

Thanks.

jessicaschilling · 2021-01-25T19:31:32Z

Apologies - you got there before I did. Thanks for the tidy summarization. Issue is #1749.

This should mitigate problem described in #1723 (comment) and help with first point of #1749 License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

This should mitigate problem described in #1723 (comment) and help with the first point of #1749

jjv360 mentioned this issue Dec 29, 2020

Investigation: 'Cannot read property 'pid' of null' #1713

Closed

jessicaschilling assigned rafaelramalho19 Jan 4, 2021

jessicaschilling added the need/analysis Needs further analysis before proceeding label Jan 4, 2021

ipfs deleted a comment from welcome bot Jan 14, 2021

jessicaschilling added need/author-input Needs input from the original author and removed need/analysis Needs further analysis before proceeding labels Jan 19, 2021

jessicaschilling mentioned this issue Jan 19, 2021

IPFS API/Updating error #1734

Closed

jessicaschilling closed this as completed Jan 25, 2021

jessicaschilling mentioned this issue Jan 25, 2021

Potential hang on "IPFS is Starting" #1749

Open

lidel added a commit that referenced this issue Jan 25, 2021

fix: timeout during checkIfAddrIsDaemon

5e0864e

This should mitigate problem described in #1723 (comment) and help with first point of #1749 License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

lidel mentioned this issue Jan 25, 2021

fix: timeout during checkIfAddrIsDaemon #1750

Merged

lidel added a commit that referenced this issue Feb 11, 2021

fix: timeout during checkIfAddrIsDaemon (#1750)

0ff806a

This should mitigate problem described in #1723 (comment) and help with the first point of #1749

lidel mentioned this issue May 21, 2021

feat: go-ipfs 0.9 #1826

Merged

6 tasks

This was referenced Apr 7, 2022

[Snyk] Security upgrade winston from 3.2.1 to 3.3.0 Kirobi92/ipfs-desktop#47

Open

[Snyk] Fix for 1 vulnerabilities baby636/ipfs-desktop#43

Open

[Snyk] Security upgrade winston from 3.2.1 to 3.3.0 thexdesk/ipfs-desktop#8

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

IPFS Desktop stuck on "IPFS is Starting" #1723

IPFS Desktop stuck on "IPFS is Starting" #1723

jjv360 commented Dec 29, 2020

jessicaschilling commented Dec 29, 2020

jjv360 commented Dec 29, 2020

jessicaschilling commented Jan 4, 2021

rafaelramalho19 commented Jan 11, 2021

NorseGaud commented Jan 14, 2021 •

edited

Loading

NorseGaud commented Jan 14, 2021

lidel commented Jan 14, 2021

lidel commented Jan 14, 2021

NorseGaud commented Jan 15, 2021

jessicaschilling commented Jan 19, 2021

jessicaschilling commented Jan 19, 2021

jjv360 commented Jan 22, 2021

rafaelramalho19 commented Jan 22, 2021

jjv360 commented Jan 23, 2021

jjv360 commented Jan 23, 2021

UnKnoWn-Consortium commented Jan 23, 2021 •

edited

Loading

UnKnoWn-Consortium commented Jan 23, 2021 •

edited

Loading

UnKnoWn-Consortium commented Jan 23, 2021 •

edited

Loading

UnKnoWn-Consortium commented Jan 23, 2021 •

edited

Loading

UnKnoWn-Consortium commented Jan 23, 2021

jjv360 commented Jan 24, 2021

jessicaschilling commented Jan 25, 2021

UnKnoWn-Consortium commented Jan 25, 2021

jessicaschilling commented Jan 25, 2021

IPFS Desktop stuck on "IPFS is Starting" #1723

IPFS Desktop stuck on "IPFS is Starting" #1723

Comments

jjv360 commented Dec 29, 2020

jessicaschilling commented Dec 29, 2020

jjv360 commented Dec 29, 2020

jessicaschilling commented Jan 4, 2021

rafaelramalho19 commented Jan 11, 2021

NorseGaud commented Jan 14, 2021 • edited Loading

NorseGaud commented Jan 14, 2021

lidel commented Jan 14, 2021

lidel commented Jan 14, 2021

NorseGaud commented Jan 15, 2021

jessicaschilling commented Jan 19, 2021

jessicaschilling commented Jan 19, 2021

jjv360 commented Jan 22, 2021

rafaelramalho19 commented Jan 22, 2021

jjv360 commented Jan 23, 2021

jjv360 commented Jan 23, 2021

UnKnoWn-Consortium commented Jan 23, 2021 • edited Loading

UnKnoWn-Consortium commented Jan 23, 2021 • edited Loading

UnKnoWn-Consortium commented Jan 23, 2021 • edited Loading

UnKnoWn-Consortium commented Jan 23, 2021 • edited Loading

UnKnoWn-Consortium commented Jan 23, 2021

jjv360 commented Jan 24, 2021

jessicaschilling commented Jan 25, 2021

UnKnoWn-Consortium commented Jan 25, 2021

jessicaschilling commented Jan 25, 2021

NorseGaud commented Jan 14, 2021 •

edited

Loading

UnKnoWn-Consortium commented Jan 23, 2021 •

edited

Loading

UnKnoWn-Consortium commented Jan 23, 2021 •

edited

Loading

UnKnoWn-Consortium commented Jan 23, 2021 •

edited

Loading

UnKnoWn-Consortium commented Jan 23, 2021 •

edited

Loading