-
Notifications
You must be signed in to change notification settings - Fork 1.2k
How do you run two nodes on a single machine? #1858
Comments
Firstly, you'll want to use the 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 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! |
Where do you think would be a good place to put this info? |
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 <alan.shaw@protocol.ai>
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? |
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 <alan.shaw@protocol.ai>
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 <alan.shaw@protocol.ai>
resolves #1858 License: MIT Signed-off-by: Alan Shaw <alan.shaw@protocol.ai>
resolves #1858 License: MIT Signed-off-by: Alan Shaw <alan.shaw@protocol.ai>
when I run this
this does not work either |
I'm not an expert on Windows but you probably want something more like: set IPFS_PATH=C:/Users/praya/.ipfs2
jsipfs daemon |
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?
The text was updated successfully, but these errors were encountered: