Das Neustarten des Geth-Knotens funktioniert weder mit dem Cron- noch mit dem Ubuntu-Upstart-Dienst richtig

Das Neustarten des Geth-Knotens funktioniert weder mit dem Cron- noch mit dem Ubuntu-Upstart-Dienst richtig

Mein Geth-Knoten fällt einmal am Tag oder so aus. Alles probiert, aber immer wieder fehlgeschlagen.

Geth 1.6.1 hängt und gibt den schwerwiegenden Fehler „unerwartete Fehleradresse“ aus

Geth auf die letzte Version aktualisiert, Kette von Grund auf neu aufgebaut, aber schlägt einmal am Tag fehl.

Daher war ein Neustartsystem erforderlich, um den Knoten am Laufen zu halten.

Der erste Versuch war, einen Cron-Eintrag wie diesen zu erstellen:

*/1 * * * * /home/mein_lokaler_benutzername/ethereum/launch.sh

das prüft, ob geth läuft oder nicht. Wenn nicht, wird Geth erneut gestartet:

!/bin/sch

env - cat /home/my_local_username/my_env.sh/bin/sh

ps auxw | grep geth | grep -v grep > /dev/null

wenn [$? != 0 ] dann /home/my_local_username/ethereum/geth --testnet --rpc --rpcapi "db,eth,net,web3,personal" --rpcport "8545" --mine --etherbase "0x8c6... " --gasprice "1000000000" --bootnodes "enode://20c..." 2> /home/my_local_username/ethereum/nohup.out fi

Die Umgebungsdatei /home/my_local_username/my_env.sh wurde mit diesem Befehl erstellt:

env > /home/my_local_username/my_env.sh

Auf diese Weise beginnt es nach 1 Minute erneut, wenn Geth fehlschlägt. Und es funktioniert und es mint, aber nicht richtig. Ich meine, wenn Geth mit dem Cron neu gestartet wird, hat es ein seltsames Verhalten. Es lässt mich kein Terminal wie dieses öffnen:

$ ./geth --testnet Attach ipc:/home/my_local_username/.ethereum/testnet/geth.ipc

Es schlägt fehl mit dem Fehler:

Schwerwiegend: Verbinden mit Remote-Geth nicht möglich: Wählen Sie Unix /home/my_local_username/.ethereum/testnet/geth.ipc: connect: Verbindung abgelehnt

Und beim Senden von Befehlen über den JSON-RPC-Link schlägt es auch mit dem Fehler fehl:

Unbekanntes Konto

Wenn Sie geth manuell von einem Shell-Terminal aus starten, funktionieren diese beiden Dinge ordnungsgemäß. Wenn sie von cron neu gestartet werden, tun sie dies nicht.

Der zweite Versuch bestand darin, einen Dienst auf Ubuntu für Geth zu erstellen, wie unter https://ethereum.stackexchange.com/a/2249/2426 erklärt

Das Ergebnis, das gleiche seltsame Verhalten: Keine Verbindung zu Geth über das Terminal und unbekannter Kontofehler beim Senden von Befehlen über den JSON-RPC-Port.

Dies ist das Protokoll von geth beim Start als Cron-Prozess:

INFO [09-14|08:20:02] Starting peer-to-peer node               instance=Geth/v1.6.5-stable-cf87713d/linux-amd64/go1.8.3
INFO [09-14|08:20:02] Allocated cache and file handles         database=/home/bitnami/.ethereum/testnet/geth/chaindata cache=128 handles=1024
INFO [09-14|08:20:06] Initialised chain configuration          config="{ChainID: 3 Homestead: 0 DAO: <nil> DAOSupport: true EIP150: 0 EIP155: 10 EIP158: 10 Metropolis: 9223372036854775807 Engine: ethash}"
INFO [09-14|08:20:06] Disk storage enabled for ethash caches   dir=/home/bitnami/.ethereum/testnet/geth/ethash count=3
INFO [09-14|08:20:06] Disk storage enabled for ethash DAGs     dir=/home/bitnami/.ethash                       count=2
INFO [09-14|08:20:06] Initialising Ethereum protocol           versions="[63 62]" network=3
INFO [09-14|08:20:06] Loaded most recent local header          number=1658958 hash=2eacdb…cdfa00 td=1833602778380180
INFO [09-14|08:20:06] Loaded most recent local full block      number=1658958 hash=2eacdb…cdfa00 td=1833602778380180
INFO [09-14|08:20:06] Loaded most recent local fast block      number=1658958 hash=2eacdb…cdfa00 td=1833602778380180
WARN [09-14|08:20:07] Blockchain not empty, fast sync disabled 
INFO [09-14|08:20:07] Starting P2P networking 
INFO [09-14|08:20:10] UDP listener up                          self=enode://d01d74c3b76f6bcf57c548d36b977b49745328566e2a12c00dded0b4ad0970518a5615cde8fd833f8f2a93b35482cf373479baf8e0c634b44123d6c8067a2615@[::]:30303
INFO [09-14|08:20:10] RLPx listener up                         self=enode://d01d74c3b76f6bcf57c548d36b977b49745328566e2a12c00dded0b4ad0970518a5615cde8fd833f8f2a93b35482cf373479baf8e0c634b44123d6c8067a2615@[::]:30303
INFO [09-14|08:20:10] IPC endpoint opened: /home/bitnami/.ethereum/testnet/geth.ipc 
INFO [09-14|08:20:10] HTTP endpoint opened: http://127.0.0.1:8545 
INFO [09-14|08:20:10] Starting mining operation 
INFO [09-14|08:20:11] Commit new mining work                   number=1658959 txs=0 uncles=0 elapsed=424.726ms
INFO [09-14|08:24:21] Block synchronisation started 
INFO [09-14|08:24:21] Mining aborted due to sync 
INFO [09-14|08:24:32] Imported new chain segment               blocks=1 txs=10 mgas=1.612 elapsed=10.313s   mgasps=0.156 number=1658959 hash=5b879b…1d974e

Ich bin ziemlich verwirrt über all diese Fehler. Jeder Hinweis darauf wäre sehr hilfreich für mich. Danke!

Referenzen:

Starten Sie Geth von einem anderen Prozess aus neu

Die Abstürze sollten nicht auftreten, hat Ihr System weniger als 4 GB RAM? Das IPC-Problem besteht darin, dass geth als der Benutzer ausgeführt wird, der Cron-Tasks startet, und nicht als Ihr Benutzer. Ein schneller schmutziger Hack ist zu verwenden sudo -u <your user> geth <other params>.
Es behebt das Problem nicht. Der Knoten hat 24 GB RAM. sudo -u <my user> startet den Geth-Knoten neu, schlägt jedoch wie oben beschrieben fehl. Thx trotzdem.
Hier nur raten (wäre im Testnet seltsam), aber stellen Sie sicher, dass NPC aktiviert ist: help.ubuntu.com/lts/serverguide/NTP.html#timesyncd
Ja, NTP aktiviert: ja - NTP synchronisiert: ja - aber immer noch dieselben Fehler.

Antworten (2)

Es hört sich so an, als ob der Socket nicht mit Ihrer Geth-Instanz verbunden ist. Ich habe hier gesehen, dass geth.ipc Probleme verursachen könnte, Sie können es versuchen:

rm -f /home/my_local_username/.ethereum/testnet/geth.ipc

Ich sehe den Fehler selbst nicht, aber diese Steckdose bleibt, wenn Geth hart getötet wird, und könnte für Sie in einem schlechten Zustand sein. Sie sollten auch die Protokolle beim Starten von geth überprüfen, um festzustellen, ob Socket-Warnungen oder -Fehler ausgegeben werden.

Ich habe den Befehl zum Entfernen des Sockets hinzugefügt, schlägt aber immer noch fehl. Und ich habe der Frage das Protokoll von geth hinzugefügt, wenn es als Cron-Prozess gestartet wird. Soweit ich sehen kann, gibt es keine Fehler oder Warnungen. Thx trotzdem.

Das ist der seltsamste Weg, den ich gesehen habe, um eine Geth-Instanz am Laufen zu halten :)

Ich schlage vor, dass Sie Folgendes tun:

  • Erstens: Wenn Sie Geth in Ihrem Terminal starten und dann das Terminal schließen, schließen Sie auch Geth.

Sie sollten Ihren Knoten in einem Terminal laufen lassen, auf das Sie per SSH in den Server zugreifen können. Ich empfehle Ihnen, Bildschirm zu verwenden .

  • Erstellen Sie als Nächstes eine Dienstkonfiguration in /etc/systemd/system. Benennen Sie es angemessen - node.servicezum Beispiel.

Verwenden Sie eine Konfiguration wie diese:

[Unit]
Description=Geth Node

[Service]
ExecStart=/usr/bin/screen -DmS node-screen -c /path/node.screenrc
ExecStop=/usr/bin/screen -S node-screen -X quit
User=root
Group=root
StandardOutput=syslog
StandardError=syslog

[Install]
WantedBy=multi-user.target

Dies weist den Dienst an, einen Bildschirm (namens node-screen) zu erstellen und ihn unter Verwendung der in node.screenrc (einer Bildschirmkonfigurationsdatei) gefundenen Konfiguration auszuführen.

  • Die Konfigurationsdatei sollte etwa Folgendes enthalten:

    screen -t 'Geth node' geth --fast --your-other-config-here

Beim Neustart Ihres Servers wird der Dienst ausgeführt und der Geth-Knoten wird neu gestartet.

  • Wenn Ihr Knoten zufällig abstürzt, können Sie ihn neu starten mit:

service node restart

  • Wenn Sie möchten, dass es ständig ausgeführt wird, können Sie die Bildschirmkonfiguration so ändern, dass ein Shell-Skript ausgeführt wird (anstatt den Knoten direkt zu starten), z. B. das folgende:

IE Setzen Sie den Geth-Startcode in eine ständig ausgeführte whileSchleife, sodass er bei einem Absturz neu gestartet wird.

#!/bin/bash

while true
do
    geth --fast --other-config
done
Das Schließen des Terminals schließt Geth nicht, da der Prozess manuell mit nohup gestartet wird
Den Ratschlägen unter ethereum.stackexchange.com/questions/1725/… folgend, habe ich versucht, einen Systemdienst unter /etc/systemd/system/geth@.service zu erstellen, und es hat funktioniert, aber das Geth-Verhalten bleibt gleich, kein Terminal und hat RPC-JSON abgelehnt Prozesse. Thx trotzdem.
Das Neustarten des Geth-Knotens funktioniert weder mit dem Cron- noch mit dem Ubuntu-Upstart-Dienst richtig
AntwortenHierDatenschutz-Bestimmungen1y, 0v