¿Por qué no se crea el archivo geth ipc, aunque dice "punto final abierto"?

Tenía un código de prueba que funcionaba bien sobre IPC usando geth listo para usar. Traté de configurar una red de prueba y rompió el cliente IPC.

Quiero ejecutar dos procesos: un proceso geth minero, que representa a la comunidad en general, y un proceso geth del servidor IPC, que representa lo que se ejecutaría en mi propio servidor web.

Aquí está el guión que captura lo que creo que debería estar haciendo.

#!/bin/bash

E="/store/ethereum/"

H="/store/home/"

D="$H/.ethereum-test"

G="geth --networkid 1100 --maxpeers 5"

PORT="--port 33301"

RPC="--rpcport 33302"

WSRPC="--wsport 33303"

IPC="--ipcapi 'admin,eth,miner,db,net,web3,personal' --ipcpath \"$E/geth.ipc\""

MINE="--mine  --minerthreads 1 -rpccorsdomain \"*\""

KS="--keystore \"$E/keystore\""

if [[ "$1" == "setup" ]]
then
    # Start fresh
    rm -rf "$D-miner"
    rm -rf "$D-client"

    # Accept conditions and type exit.
    $G --genesis test-genesis.json -nodiscover -maxpeers 0 --datadir "$D-miner" console
elif [[ "$1" == "newacc" ]]
then
    # Enter passphrase and note address.
    # Last generated address:
    # bcd47eee60f5d8f73977785a55ab081bf8f37582
    # 5b3e83ff30e61287cf2d8eed5b8c1ead40d10432
    # a770c607f4bde0cdf1fa84e8721e9b53fce8a176
    # (older)
    $G $KS --datadir $D-miner account new
elif [[ "$1" == "mine" ]]
then
    # Mine
    $G $MINE $KS --datadir $D-miner $PORT
elif [[ "$1" == "ipc" ]]
then
    $G --datadir $D-client $IPC
else
    echo "Argument: setup newacc mine or ipc"
fi

Lo uso así.

En la terminal A:

./testnet setup
./testnet newacc
./testnet mine

La minería funciona bien.

En la terminal B:

./testnet ipc

Este parece funcionar bien. Muestra que creó $E/geth.ipccomo se prometió.

Entonces aquí está el NodeJS que funcionó bien antes:

var web3_extended = require ('web3_extended');

var options =
{
        host:     './geth.ipc',
        ipc:      true,
        personal: true, 
        admin:    false,
        debug:    false
};

var web3 = web3_extended .create (options);

Esto produce

IPC Connection Error { [Error: connect ENOENT] code: 'ENOENT', errno: 'ENOENT', syscall: 'connect' }

Lo extraño es que geth en la terminal B genera esta línea

I0427 12:53:00.381003 node/node.go:298] IPC endpoint opened: "/ethereum/geth.ipc"

Pero si yols /ethereum/geth.ipc

No se crea tal archivo (como sucedió con vanilla geth). Sí, tengo permisos de escritura en este directorio. El minero en la terminal A crea su geth.ipc en otro lugar.

¿Qué salió mal?

EDITAR

Miner produce esta salida cuando se inicia con

geth --networkid 1100 --maxpeers 5 --mine --minerthreads 1 -rpccorsdomain "*" --datadir /ethereum/.ethereum-test-miner --port 33301

Y el servidor IPC produce esta salida cuando se inicia con

geth --networkid 1100 --maxpeers 5 --datadir /ethereum/.ethereum-test-client --ipcapi 'admin,eth,miner,db,net,web3,personal' --ipcpath "/ethereum/geth.ipc"
¿Podría abrir un informe de errores en nuestro rastreador de problemas? github.com/ethereum/go-ethereum/problemas

Respuestas (1)

(Esta página se reorganizará cuando se resuelva este problema)

EDITAR 30/04/2016

@spraff, mirando sus últimos datos:

Miner produce esta salida cuando se inicia con

geth --networkid 1100 --maxpeers 5 --mine --minerthreads 1 -rpccorsdomain "*" --datadir /ethereum/.ethereum-test-miner --port 33301

Y el servidor IPC produce esta salida cuando se inicia con

geth --networkid 1100 --maxpeers 5 --datadir /ethereum/.ethereum-test-client --ipcapi 'admin,eth,miner,db,net,web3,personal' --ipcpath "/ethereum/geth.ipc"

las rutas del archivo IPC parecen correctas. Sin embargo, parece que está intentando vincular su minero con su cliente IPC utilizando el protocolo IPC.

El protocolo IPC está destinado a vincular un nodo (minero o no minero) a un cliente (por ejemplo, visor geth attach ipc://path/geth.ipcde consola como Ethereum Wallet o cliente web).

Lo que probablemente quiera hacer es crear una red Ethereum privada con sus clientes mineros y clientes no mineros conectados a la misma red blockchain. Esto se hace usando los mismos indicadores --networkidy , Y luego vincula todos los clientes mineros y no mineros usando el parámetro, o usando el archivo de configuración o .--genesis--bootnodesstatic-nodes.jsontrusted-nodes.json

Puede encontrar el método para vincular los clientes en Peer discovery que no funciona en una red privada . Parte de la información también está disponible en La conexión entre pares nunca ocurre en una cadena de bloques personalizada .


COSAS VIEJAS ABAJO



Pregunta para @spraff

  1. ¿Qué versión gethestás ejecutando en tus diferentes terminales?

    Parece que está ejecutando la versión de rama de desarrollogeth en la terminal donde se encuentra con el --ipcpathproblema.

    Es posible que desee intentar usar la versión de rama maestrageth de donde --ipcpathparece estar funcionando.

    Aún debe presentar un informe de error como lo sugiere @Péter Szilágyisi --ipcpathno funciona con la versión de rama de desarrollogeth de .

  2. ¿Hay más de una versión de gethinstalada en su computadora (y en sus diferentes terminales)? Verifique con los comandos:

    find / -name 'geth'
    ls -al `which geth`
    

    ¿Está ejecutando la versión gethque pretende ejecutar?



Desplegando tus comandos

Su archivo de secuencia de comandos es un poco complicado de leer, por lo que he desenrollado los comandos.

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"

Este parece funcionar bien. Da como resultado que creó $E/geth.ipc como se prometió.

Entonces el archivo IPC /store/ethereum/geth.ipcse crea como se esperaba

Lo extraño es que geth en la terminal B genera esta línea

I0427 12:53:00.381003 node/node.go:298] IPC endpoint opened: "/ethereum/geth.ipc"

Pero si ls /ethereum/geth.ipcno se crea dicho archivo (como sucedió con Vanilla Geth). Sí, tengo permisos de escritura en este directorio. El minero en la terminal A crea su geth.ipc en otro lugar. ¿Qué salió mal?



Problema 1: ¿Qué versión gethestá ejecutando o pretende ejecutar?

Encontré node/node.go en la rama de desarrollo go-ethereum con el siguiente código:

go func() {
    glog.V(logger.Info).Infof("IPC endpoint opened: %s", n.ipcEndpoint)

Cuando ejecuto gethen mi computadora, recibo el siguiente mensaje:

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

El --ipcpathcomando funciona correctamente en mi versión de 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



prueba de ipc

He usado su último comando para probar la ruta del archivo IPC:

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)

Entonces parece estar funcionando para mi gethversión en Linux.

Aquí está su gethcomando con el resultado que proporcionó en su enlace:

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")

Pero tampoco funciona para su gethversión en Linux.

Nota : /ethereumestá en su directorio raíz. Normalmente, los procesos no pueden crear archivos en el directorio raíz sin permiso de superusuario. Quizás esta sea la razón.

Acabo de volver a probar usando el comando:

geth --networkid 1100 --maxpeers 5                \
  --datadir ./eth/.ethereum-test-client           \
  --ipcapi 'admin,eth,miner,db,net,web3,personal' \
  --ipcpath "/ethereum/geth.ipc"

Y este es el mensaje de error que recibo:

Fatal: Error string IPC: mkdir /ethereum: permission denied

Creé el subdirectorio /ethereumsin cambiar los permisos:

sudo mkdir /ethereum

Y al ejecutar el último gethcomando nuevamente, aparece un mensaje de error diferente:

Fatal: Error string IPC: listen unix /ethereum/geth.ipc: bind: permission denied

Ahora estoy cambiando la propiedad del directorio:

sudo chown user:user /ethereum

Y funciona:

I0428 09:29:10.777981   22740 ipc.go:112] IPC service started (/ethereum/geth.ipc)

Mmm. Lo pensaré un poco más.

¡Gracias esto parece muy útil! Estaba ejecutando Version: 1.5.0-unstabledesde Ubuntu ethereum-dev PPA, lo purgué y lo reinstalé Version: 1.3.6; es muy posible que sea así, aunque esta versión no tiene la --keystorebandera. ¿Puedes comentar sobre esto? Muchas gracias.
Si necesita configurar el directorio del almacén de claves en cualquier otro lugar que no sea el subdirectorio --datadir, simplemente use enlaces suaves como se muestra en ethereum.stackexchange.com/questions/3402/… .
No, esto no es todo. Eliminé las banderas del almacén de claves, pero el problema persiste cuando estoy ejecutando 1.3.6 SIN EMBARGO, el comando geth --ipcapi "db,eth,net,web3,personal" --ipcpath "$P/geth.ipc"funciona normalmente (para el mismo binario), es solo que ahora no estoy en la red de prueba.
¿Puede proporcionar los detalles completos del comando 1.3.6 que no funciona, con todas las opciones expandidas?
Minero: geth --networkid 1100 --maxpeers 5 --mine --minerthreads 1 -rpccorsdomain "*" --datadir /eth/.ethereum-test-miner --port 33301Servidor IPC:geth --networkid 1100 --maxpeers 5 --datadir /eth/.ethereum-test-client --ipcapi 'admin,eth,miner,db,net,web3,personal' --ipcpath "/eth/geth.ipc"
¿Es solo la versión del servidor IPC la que no funciona? ¿Qué sucede cuando agrega una "consola" al final de este comando? ¿Puede agregar los mensajes iniciales de inicio al final de su pregunta original?
Sin preocupaciones. Ethereum.SE es parte de mi investigación sobre Ethereum. Encontré mi primer caso de uso utilizando contratos inteligentes para un cliente ayer, así que estoy satisfecho. Probaré sus opciones de línea de comando contra su salida en unas pocas horas.
Probé usando su comando y obtuve diferentes resultados de usted. Tendré que pensarlo un poco más.