geth --fast sync extremely slow when run under systemd

Question

I have dedicated an intel atom laptop with 2GB of memory and a 300+GB SSD as my ethereum node. I am running geth as systemd daemon. Now it's been running 3+ days day and night, with the command:

geth --fast --cache=1024 --jitvm 2

But alas, I open ethereum wallet and it says I have only 1% of the blockchain donwloaded.. (I am behind a 10Mbps connection to the internet)

Using

geth attach

and then

eth.syncing

gives

{ currentBlock: 178336, highestBlock: 3405682, knownStates: 1069106, pulledStates: 1000195, startingBlock: 105918 }

This is madness..! Or do I need a supercomputer, attached to a nuclear reactor just to download the blockchain? Now it seems that it will take two months in total ..

EDIT (the next day)

Good evening. Today we're at

{ currentBlock: 258502, highestBlock: 3411279, knownStates: 58508, pulledStates: 21838, startingBlock: 256974 }

Looking at the number of peers, it seems there are 24

admin.peers.length
24

Thanks for the suggestion, but the number of peers does not seem to be the issue.. how could I check if NAT traversal is an issue..? I have configured my router to forward everything to my home server.. (no firewalls, NATs, nothing)

EDIT after a few days

Still going strong

{ currentBlock: 887422, highestBlock: 2283547, knownStates: 2144, pulledStates: 126, startingBlock: 887418 }

This Ethereum thing is so great.

EDIT (after a few more days)

eth.syncing { currentBlock: 908606, highestBlock: 1211334, knownStates: 70444, pulledStates: 7563, startingBlock: 906796 }

I'm using at the moment

geth --fast --cache=512 --nat=none

Memory usage:

               total       used        free      shared  buff/cache   available
Mem:           1,9G        1,4G         69M         20M        505M        380M
Swap:          2,0G         99M        1,9G

.. so not gone completely swappy either.

It's also weird that the highest block should be, according to "ethstats.net" 3 million+. It's correct in the first "eth.syncing" I've written here, but in the last update its only one million+ ???

Don't know if it's a bug in the pre-packacked .deb distro (lots of people seem to have problems with them..) or what.

This'll be enough ethereum for me at the moment ..not quite plug'n'play yet

EDIT:

So, I downloaded go-ethereum from github, golang from google, etc. Now I have geth compiled from source.

I am running with

geth --cache=512 --nat=none

Still no success. It started quite well.. after 3-hours or so, I got

{ currentBlock: 967477, highestBlock: 3551915, knownStates: 6218249, pulledStates: 6218249, startingBlock: 0 }

.. but after it's been running for 24h+ (I have 9 peers at the moment):

eth.syncing { currentBlock: 989279, highestBlock: 3558249, knownStates: 149529, pulledStates: 127316, startingBlock: 973578 }

I'm am starting to be convinced that this is a russian Ponzi-scheme (as someone suggested..) .. ! :-o

Answer 1

Well, indeed.

The root of the problem was the linux systemd (or my poor knowledge of it). I was running geth as systemd daemon, but with

systemctl --user enable geth.service

etc. commands. Now, when systemd is used as per-user daemon, it kills the daemons associated to a certain user, when that user logs out.

For this reason, always when I logged out from my ethereum node, geth was shut down and always when I re-logged in, it started again (what a stealthy f*****!) .. and it seemed there was no progress. I found this out looking at the systemd logs.

What an embarrasement! Sorry about my ponzi-scheme comments, but I was getting soo frustrated..

Hopefully someone finds this useful (or if not, amusing at least).

Answer 2

Did you use sudo loginctl enable-linger $username?

This will treat your user services as background processes and maintain user ownership, but it mimics root processes by running regardless of whether you log out or back into your terminal.