Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

How do you run two nodes on a single machine? #1858

Closed
mikeal opened this issue Jan 31, 2019 · 5 comments · Fixed by #1916
Closed

How do you run two nodes on a single machine? #1858

mikeal opened this issue Jan 31, 2019 · 5 comments · Fixed by #1916
Assignees
Labels
kind/support A question or request for support P3 Low: Not priority right now

Comments

@mikeal
Copy link
Contributor

mikeal commented Jan 31, 2019

I’m on the latest js-ipfs on Node.js v10 on Linux.

I’m writing a command line utility and each invocation of the utility creates an IPFS node. The first one runs fine, but when I try to do a second invocation while the first is still running the new invocation just exits. No error, no exception, nothing, just an exit.

This is because the ready event never fires and because the node never binds to a port the process runs out of things to do and just exits. I suspect this is due to listen port conflicts, so I attempted to change the ports, that I’m sort of lost in the layers where the config I’m trying to pass in actually makes it to libp2p, I’m not sure what exactly I’m doing wrong because I never get an error — the process just exits.

Anyway, is there a guide or example anywhere of all the little things I need to adjust to run two nodes on the same machine?

@alanshaw
Copy link
Member

alanshaw commented Jan 31, 2019

Firstly, you'll want to use the IPFS_PATH env variable or pass the repo option to the constructor to get a different repo for each instance.

e.g.

CLI:

IPFS_PATH=~/.jsipfs2 jsipfs init

Programmatically:

new IPFS({ repo: os.homedir() + '/.jsipfs2' })

Secondly, you'll need them to bind to different ports because otherwise bad things happen.

With the CLI, after you've run ipfs init you can either edit the config file at ~/.jsipfs/config (replacing ~/.jsipfs with the repo path you specified above) or use the config command to update the config e.g. ipfs config Addresses.API /ip4/0.0.0.0/tcp/4012. Then start the node with ipfs daemon. Or if you're doing this programmatically you can simply pass the different ports to the config constructor option.

e.g.

CLI:

# edit the address ports
vi ~/.jsipfs2/config

# ...and then start the daemon
IPFS_PATH=~/.jsipfs2 jsipfs daemon

or

IPFS_PATH=~/.jsipfs2 jsipfs config Addresses.API /ip4/127.0.0.1/tcp/5012
# etc...

# ...and then start the daemon
IPFS_PATH=~/.jsipfs2 jsipfs daemon

Programmatically:

new IPFS({
  config: {
    Addresses: {
      Swarm: [
        '/ip4/0.0.0.0/tcp/4012',
        '/ip4/127.0.0.1/tcp/4013/ws'
      ],
      API: '/ip4/127.0.0.1/tcp/5012',
      Gateway: '/ip4/127.0.0.1/tcp/9191'
    }
  }
})

Thirdly, yes I've noticed error's being swallowed and I intend to fix it asap. Issue here libp2p/js-libp2p#311 and I'll double check if this is a problem in JS IPFS or not now.

Hope that helps!

@alanshaw alanshaw added kind/support A question or request for support status/in-progress In progress P3 Low: Not priority right now labels Jan 31, 2019
@alanshaw
Copy link
Member

Where do you think would be a good place to put this info?

alanshaw pushed a commit that referenced this issue Jan 31, 2019
The switch to using `yargs-promise` for `ipfs init` and `ipfs daemon` commands caused an unhandled promise rejection and in some cases would cause an error to not be printed to the console.

This PR greatly simplifies the code in `src/cli/bin.js`, to always use `yargs-promise`. Command handlers are now passed an async `getIpfs` function instead of an `ipfs` instance. It means that we don't have to differentiate between commands that use an IPFS instance in `src/cli/bin.js`, giving the handler the power to call `getIpfs` or not to obtain an IPFS instance as and when needed. This removes a whole bunch of complexity from `src/cli/bin.js` at the cost of adding a single line to every command handler that needs to use an IPFS instance.

This enables operations like `echo "hello" | jsipfs add -q | jsipfs cid base32` to work without `jsipfs cid base32` failing because it's trying to acquire a repo lock when it doesn't use IPFS at all.

fixes #1835
refs #1858
refs libp2p/js-libp2p#311

License: MIT
Signed-off-by: Alan Shaw <[email protected]>
@alanshaw alanshaw mentioned this issue Jan 31, 2019
1 task
@mikeal
Copy link
Contributor Author

mikeal commented Jan 31, 2019

Where do you think would be a good place to put this info?

The code one we should use in a new example in the examples directory. The CLI stuff I’m less sure about, maybe we need some different doc files with notes on common use cases we can just link to in the main README?

alanshaw pushed a commit that referenced this issue Feb 5, 2019
The switch to using `yargs-promise` for `ipfs init` and `ipfs daemon` commands caused an unhandled promise rejection and in some cases would cause an error to not be printed to the console.

This PR greatly simplifies the code in `src/cli/bin.js`, to always use `yargs-promise`. Command handlers are now passed an async `getIpfs` function instead of an `ipfs` instance. It means that we don't have to differentiate between commands that use an IPFS instance in `src/cli/bin.js`, giving the handler the power to call `getIpfs` or not to obtain an IPFS instance as and when needed. This removes a whole bunch of complexity from `src/cli/bin.js` at the cost of adding a single line to every command handler that needs to use an IPFS instance.

This enables operations like `echo "hello" | jsipfs add -q | jsipfs cid base32` to work without `jsipfs cid base32` failing because it's trying to acquire a repo lock when it doesn't use IPFS at all.

fixes #1835
refs #1858
refs libp2p/js-libp2p#311

License: MIT
Signed-off-by: Alan Shaw <[email protected]>
alanshaw pushed a commit that referenced this issue Feb 6, 2019
The switch to using `yargs-promise` for `ipfs init` and `ipfs daemon` commands caused an unhandled promise rejection and in some cases would cause an error to not be printed to the console.

This PR greatly simplifies the code in `src/cli/bin.js`, to always use `yargs-promise`. Command handlers are now passed an async `getIpfs` function instead of an `ipfs` instance. It means that we don't have to differentiate between commands that use an IPFS instance in `src/cli/bin.js`, giving the handler the power to call `getIpfs` or not to obtain an IPFS instance as and when needed. This removes a whole bunch of complexity from `src/cli/bin.js` at the cost of adding a single line to every command handler that needs to use an IPFS instance.

This enables operations like `echo "hello" | jsipfs add -q | jsipfs cid base32` to work without `jsipfs cid base32` failing because it's trying to acquire a repo lock when it doesn't use IPFS at all.

fixes #1835
refs #1858
refs libp2p/js-libp2p#311

License: MIT
Signed-off-by: Alan Shaw <[email protected]>
alanshaw pushed a commit that referenced this issue Mar 11, 2019
resolves #1858

License: MIT
Signed-off-by: Alan Shaw <[email protected]>
@ghost ghost assigned alanshaw Mar 11, 2019
@ghost ghost removed the status/in-progress In progress label Mar 11, 2019
alanshaw pushed a commit that referenced this issue Mar 11, 2019
resolves #1858

License: MIT
Signed-off-by: Alan Shaw <[email protected]>
@prayaglehana
Copy link

prayaglehana commented Oct 4, 2019

when I run this
IPFS_PATH=C:/Users/praya/.ipfs2 ipfs daemon
IPFS_PATH is not recognized as an internal or external command

set `IPFS_PATH=C:/Users/praya/.ipfs2 ipfs daemon`   
`IPFS_PATH=C:/Users/praya/.ipfs2 ipfs daemon`   

this does not work either

@alanshaw
Copy link
Member

I'm not an expert on Windows but you probably want something more like:

set IPFS_PATH=C:/Users/praya/.ipfs2
jsipfs daemon

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/support A question or request for support P3 Low: Not priority right now
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants