(This page will be reorganised when this problem is solved)
EDIT 30/04/2016
@spraff, looking at your latest data:
Miner produces this output when started with
geth --networkid 1100 --maxpeers 5 --mine --minerthreads 1 -rpccorsdomain "*" --datadir /ethereum/.ethereum-test-miner --port 33301
And IPC server produces this output when started with
geth --networkid 1100 --maxpeers 5 --datadir /ethereum/.ethereum-test-client --ipcapi 'admin,eth,miner,db,net,web3,personal' --ipcpath "/ethereum/geth.ipc"
the IPC file paths look correct. It does however seems like you are trying to link your miner with your IPC client using the IPC protocol.
The IPC protocol is meant to link a node (mining or non-mining) to a client (e.g. console viewer like geth attach ipc://path/geth.ipc, Ethereum Wallet or web client).
What you probably want to do is to create a private Ethereum network with both your mining clients and non-mining clients connected to the same blockchain network. This is done using the same --networkid and --genesis flags, AND you then link all mining and non-mining clients using the --bootnodes parameter, or using either the static-nodes.json or trusted-nodes.json configuration file.
You can find the method to link the clients at Peer discovery not working on private network . Some information is also available at Connection between peers never happen on custom blockchain .
OLD STUFF BELOW
Question For @spraff
What version geth are you running in your different terminals?
You seem to be running the develop branch version of geth in the terminal where you are encountering the --ipcpath issue.
You may want to try using the master branch version of geth where the --ipcpath seems to be working.
You should still lodge a bug report as suggested by @Péter Szilágyi if the --ipcpath does not work with the develop branch version of geth.
Is there more than one version of geth installed on your computer (and in your different terminals) ? Check with the commands:
find / -name 'geth'
ls -al `which geth`
Are you running the version of geth that you intend to run?
Unrolling your commands
Your script file is a little bit complicated to read, so I've unrolled the commands.
Terminal A
# ./testnet setup
rm -rf /store/home//.ethereum-test-miner
rm -rf /store/home//.ethereum-test-client
geth --networkid 1100 --maxpeers 5 \
--genesis test-genesis.json -nodiscover -maxpeers 0 \
--datadir "/store/home//.ethereum-test-miner" console
# ./testnet newacc
geth --networkid 1100 --maxpeers 5 \
--keystore "/store/ethereum//keystore" \
--datadir /store/home//.ethereum-test-miner account new
# ./testnet mine
geth --networkid 1100 --maxpeers 5 \
--mine --minerthreads 1 -rpccorsdomain "*" \
--keystore "/store/ethereum//keystore" \
--datadir /store/home//.ethereum-test-miner \
--port 33301
Terminal B
# ./testnet ipc
geth --networkid 1100 --maxpeers \
--datadir /store/home//.ethereum-test-client \
--ipcapi 'admin,eth,miner,db,net,web3,personal' \
--ipcpath "/store/ethereum//geth.ipc"
This one appears to work fine. It outputs that it created $E/geth.ipc as promised.
So the IPC file /store/ethereum/geth.ipc is created as expected
What's odd is that geth in terminal B outputs this line
I0427 12:53:00.381003 node/node.go:298] IPC endpoint opened: "/ethereum/geth.ipc"
But if I ls /ethereum/geth.ipc
No such file is created (as it was with vanilla geth). Yes, I have write permissions to this directory. The miner in terminal A creates its geth.ipc elsewhere.
What's gone wrong?
Issue 1 - What version of geth are you running, or intend to run?
I've found node/node.go in the go-ethereum develop branch with the following code:
go func() {
glog.V(logger.Info).Infof("IPC endpoint opened: %s", n.ipcEndpoint)
When I run geth on my computer, I get the following message:
I0428 00:42:38.207812 14842 ipc.go:112] IPC service started (/home/user/.ethereum/geth.ipc)
instance: Geth/v1.3.6/linux/go1.5.1
The --ipcpath command works correctly in my version of geth:
$ geth --ipcpath /tmp/geth.ipc console
I0428 01:24:01.896976 20433 ipc.go:112] IPC service started (/tmp/geth.ipc)
instance: Geth/v1.3.6/linux/go1.5.1
Testing IPC
I've used your latest command to test out the IPC file path:
user@Kumquat:/tmp$ geth --networkid 1100 --maxpeers 5 \
--datadir ./eth/.ethereum-test-client \
--ipcapi 'admin,eth,miner,db,net,web3,personal' \
--ipcpath "./eth/geth.ipc"
...
I0428 09:14:09.309467 22639 cmd.go:115] Starting Geth/v1.3.6/linux/go1.5.1
I0428 09:14:10.789959 22639 ipc.go:112] IPC service started (eth/geth.ipc)
So it seems to be working for my geth version on Linux.
Here is your geth command with the output you provided in your link:
geth --networkid 1100 --maxpeers 5 \
--datadir /eth/.ethereum-test-client \
--ipcapi 'admin,eth,miner,db,net,web3,personal' \
--ipcpath "/eth/geth.ipc"
...
I0427 22:24:27.875773 30370 cmd.go:115] Starting Geth/v1.3.6/linux/go1.5.1
I0427 22:24:30.222976 30370 ipc.go:112] IPC service started ("/ethereum/geth.ipc")
But it is not working for your geth version on Linux as well.
Note: /ethereum is on your root directory. Normally processes cannot create files on the root directory without superuser permission. Perhaps this is the reason.
I've just re-tested using the command:
geth --networkid 1100 --maxpeers 5 \
--datadir ./eth/.ethereum-test-client \
--ipcapi 'admin,eth,miner,db,net,web3,personal' \
--ipcpath "/ethereum/geth.ipc"
And this is the error message I get:
Fatal: Error string IPC: mkdir /ethereum: permission denied
I created the subdirectory /ethereum without changing the permissions:
sudo mkdir /ethereum
And running the last geth command again, get a different error message:
Fatal: Error string IPC: listen unix /ethereum/geth.ipc: bind: permission denied
I'm now changing the ownership of the directory:
sudo chown user:user /ethereum
And it works:
I0428 09:29:10.777981 22740 ipc.go:112] IPC service started (/ethereum/geth.ipc)
Hmmm. I'll think about it a bit more.
Best Answer
Turns out this was a networking question.
I had to port forward TCP and UDP ports 30303 on the router to my VM's IP address.
After doing that and restarting geth, the chain began to synchronize almost immediately.