IPFS crashes on second run on windows

[slothbag]

I just compiled latest master and I could not start IPFS with this error:

Error: Post http://127.0.0.1:5001/api/v0/version?enc=json&stream-channels=true: dial tcp 127.0.0.1:5001: ConnectEx tcp: No connection could be made because the target machine actively refused it.

I issued a ipfs init and then I was able to start the daemon successfully. But after ctrl-c quiting the daemon I tried running it again and got the same error as above.

[myrkvi]

I have the same issue with 0.3.8 on Windows 10.

[jbenet]

Bizarre. @gatesvp ?

[Mithgol]

I have the same problem with https://gobuilder.me/get/github.com/ipfs/go-ipfs/cmd/ipfs/ipfs_master_windows-amd64.zip on Windows 7, see #1713 (a closed duplicate of this issue) for a screenshot.

Not only ipfs daemon is affected but ipfs id as well.

[jbenet]

:/ we need to fix this. Any ideas what's going on here? @whyrusleeping @gatesvp?

—
Sent from Mailbox

On Wed, Sep 16, 2015 at 2:47 AM, Mithgol notifications@github.com wrote:

I have the same problem with https://gobuilder.me/get/github.com/ipfs/go-ipfs/cmd/ipfs/ipfs_master_windows-amd64.zip on Windows 7, see #1713 for a screenshot.

Not only ipfs daemon is affected but ipfs id as well.

Reply to this email directly or view it on GitHub:
#1661 (comment)

[whyrusleeping]

probably the locking library failing to properly clean up on exit. I'm not super knowledgeable on how windows file locking works, but we might have to special case some things if the syscalls arent reliable like they are on osx, linux and the bsd's

[gatesvp]

Was actually trying to look at this last night, but had a different problem
just trying to build the Windows version because of Symlinks in the main
repo.

Don't know if the problem is file locking or ports. Hope to spend some time
tonight debugging.

On Wed, Sep 16, 2015 at 9:13 AM, Jeromy Johnson notifications@github.com
wrote:

probably the locking library failing to properly clean up on exit. I'm not
super knowledgeable on how windows file locking works, but we might have to
special case some things if the syscalls arent reliable like they are on
osx, linux and the bsd's

—
Reply to this email directly or view it on GitHub
#1661 (comment).

[chriscool]

If we want to properly support Windows, we might want to have automated builds and tests for this platform. Is there an issue somewhere for that or should I create one?

[gatesvp]

I feel like there was a ticket somewhere. One of the challenges with such a
ticket is effectively re-creating the sharness tests in say Windows
PowerShell.

Also, I managed to repro the problem locally last night, but still trying
to debug my way through the actual issue.

On Thu, Sep 17, 2015 at 7:58 AM, Christian Couder notifications@github.com
wrote:

If we want to properly support Windows, we might want to have automated
builds and tests for this platform. Is there an issue somewhere for that or
should I create one?

—
Reply to this email directly or view it on GitHub
#1661 (comment).

[Mithgol]

This comment is just a nudge because ≈7 days have passed since the last comment here.

Please excuse my impatience.

[jbenet]

Mithgol, can you help fix it? None of the core devs use windows. Gatesvp and others have done tremendous work on getting things working on windows, but we need everybody's help to move fast

—
Sent from Mailbox

On Thu, Sep 24, 2015 at 8:42 AM, Mithgol notifications@github.com wrote:

This comment is just a nudge because ≈7 days have passed since the last comment here.

Please excuse my impatience.

Reply to this email directly or view it on GitHub:
#1661 (comment)

[Mithgol]

Unfortunately, I don't know Go. (Otherwise I would have already tried to help.)

[ghost]

Hi, I worked around this in the referencing commit. I know neither Go nor ipfs codebase nor Windows APIs, so I don't know if this is the desired way of doing things.

[Mithgol]

I know neither Go not IPFS codebase, but the line you added does look very much like the previous and thus it can't be much worse in terms of desired way of doing things.

You should make a pull request and become a contributor.

[jbenet]

@mjanczyk thank you for the PR

[jbenet]

and thanks @Mithgol for prompting it!

[richardschneider]

I don't know about the code. But the reason why we can't restart on windows, is the presence of the .../.ipfs/api file. If I delete it, then ipfs daemon works!

As suspected by others, its most likely a cleanup issue of the daemon.

[jbenet]

• is anyone having this issue in other systems?
• @richardschneider what version? do you have latest 0.3.8?
• @richardschneider i think this is another issue, if you're on latest and you still see it, pls open another issue

[slothbag]

The original issue "crashing on second run in windows" has been fixed for a few weeks.

This ticket can be closed.

[richardschneider]

I'm running 0.3.8 and still having the problem.