Whenever I attempt to run geth on the command line, it seems to have trouble syncing with the blockchain. I am getting these warnings continuously (this is run on testnet).
geth --testnet --rpc --rpcaddr "localhost" --rpccorsdomain "*" --rpcapi="db,eth,net,web3,personal,staker,net,txpool,shh " --rpcport 8545
I just exited my command prompt, and restarted the geth upgradedb process and it worked.
Another solution is set the current head of the local chain to a few blocks back with debug.setHead command. That rewind the chain back to the faulty snapshot block (epoch transaction), for all the signer nodes.
Like:
debug.setHead("0x124F80") // (1200000 th block)
From #karalabe's answer on the closed issue:
There was a bug in one Geth release (v1.8.14/v1.8.15) that violated
the Clique consensus spec, causing some signers to create blocks when
they weren't allowed to (epoch transition). All previous and
subsequent version of Geth (apart from the faulty one) correctly
rejected those blocks, hence why you couldn't sync a new node to your
already mined chain.
A node however does not re-validate blocks when you update it, so even
though you updated your signers, they were oblivious to the fact that
a faulty block was already in their chain. When you rewound the chain,
the signers had to re-mine the faulty segment, correcting the issue.
This should most definitely not happen again, as long as you don't use
the faulty version of Geth. Any version equal or above to v1.8.16
should work just fine.
Related
Everything run well when i restarted running command "geth" for my local private network. but when i restarted my pc and run the geth command again, the block reset to 0 again.
Here is my code to init the geth from configuration in my genesis.json:
geth --datadir "/PATH_TO_NODE/" init /PATH_TO/genesis.json
And then i run my geth node with command:
geth --identity "node01" --http --http.port "8000" --http.corsdomain "*" --datadir "/PATH_TO_NODE/" --nodiscover --http.api "eth,net,web3,personal,miner,admin" --networkid 1900 --allow-insecure-unlock
when i rerun the command above there is no problem, it will continuing the block that already there. But it will be resetting to the 0 again when i restart my PC. Is it intended or not?
I believe this is because you've ran your geth node with a different network ID (--networkid 1900) rather than the default which is hardcoded as 1 and will have been used when you ran your first command (without the flag above). Every time you do this it resets the chain data. Also afaik, putting network ID in the genesis doesn't actually change anything. The only ways to change it are to a) hardcode it in the codebase or use the flag.
My first problem looked like this:
Writing objects: 60% (9/15)
It freezed there for some time with very low upload speed (in kb/s), then, after long time, gave this message:
fatal: the remote end hung up unexpectedly
Everything up-to-date
I found something what seemed to be a solution:
git config http.postBuffer 524288000
This created a new problem that looks like this:
MacBook-Pro-Liana:LC | myWebsite Liana$ git config http.postBuffer 524288000
MacBook-Pro-Liana:LC | myWebsite Liana$ git push -u origin master
Enumerating objects: 15, done.
Counting objects: 100% (15/15), done.
Delta compression using up to 4 threads
Compressing objects: 100% (14/14), done.
Writing objects: 100% (15/15), 116.01 MiB | 25.16 MiB/s, done.
Total 15 (delta 2), reused 0 (delta 0)
error: RPC failed; curl 56 LibreSSL SSL_read: SSL_ERROR_SYSCALL, errno 54
fatal: the remote end hung up unexpectedly
fatal: the remote end hung up unexpectedly
Everything up-to-date
Please help, I have no idea what’s going on...
First, Git 2.25.1 made it clear that:
Users in a wide variety of situations find themselves with HTTP push problems.
Oftentimes these issues are due to antivirus software, filtering proxies, or other man-in-the-middle situations; other times, they are due to simple unreliability of the network.
This works for none of the aforementioned situations and is only useful in a small, highly restricted number of cases: essentially, when the connection does not properly support HTTP/1.1.
Raising this is not, in general, an effective solution for most push problems, but can increase memory consumption significantly since the entire buffer is allocated even for small pushes.
Second, it depends on your actual remote (GitHub? GitLab? BitBucket? On-premise server). Said remote server might have an incident in progress.
When I try to replicate a remote couchdb (on ubuntu 14.04- 64 bit) with my local pouchdb, I encouter this strange error.
My couchdb is proxied via nginx and running on https. Traffic from client to nginx is ssl while nginx to couchdb is simple http. Cors requests are enabled in couchdb. Nginx configuration is most similar to couchdb recommended. Sync from database is working fine however getting below errors when debugging via chrome Version 54.0.2840.100 (64-bit) .
Following is the full stack trace of the error.
raven.min.js:2 Error: There was a problem getting docs.
at finishBatch (http://localhost:8100/lib/pouchdb/dist/pouchdb.js:6410:13)
at processQueue (http://localhost:8100/lib/ionic/js/ionic.bundle.js:27879:28)
at http://localhost:8100/lib/ionic/js/ionic.bundle.js:27895:27
at Scope.$eval (http://localhost:8100/lib/ionic/js/ionic.bundle.js:29158:28)
at Scope.$digest (http://localhost:8100/lib/ionic/js/ionic.bundle.js:28969:31)
at http://localhost:8100/lib/ionic/js/ionic.bundle.js:29197:26
at completeOutstandingRequest (http://localhost:8100/lib/ionic/js/ionic.bundle.js:18706:10)
at http://localhost:8100/lib/ionic/js/ionic.bundle.js:18978:7
at d (http://localhost:8100/lib/raven-js/dist/raven.min.js:2:4308) undefineda.(anonymous function) # raven.min.js:2(anonymous function) # ionic.bundle.js:25642(anonymous function) # ionic.bundle.js:22421(anonymous function) # angular.min.js:2processQueue # ionic.bundle.js:27887(anonymous function) # ionic.bundle.js:27895$eval # ionic.bundle.js:29158$digest # ionic.bundle.js:28969(anonymous function) # ionic.bundle.js:29197completeOutstandingRequest # ionic.bundle.js:18706(anonymous function) # ionic.bundle.js:18978d # raven.min.js:2
raven.min.js:2 Paused in lessondb replicate Error: There was a problem getting docs.
at finishBatch (http://localhost:8100/lib/pouchdb/dist/pouchdb.js:6410:13)
at processQueue (http://localhost:8100/lib/ionic/js/ionic.bundle.js:27879:28)
at http://localhost:8100/lib/ionic/js/ionic.bundle.js:27895:27
at Scope.$eval (http://localhost:8100/lib/ionic/js/ionic.bundle.js:29158:28)
at Scope.$digest (http://localhost:8100/lib/ionic/js/ionic.bundle.js:28969:31)
at http://localhost:8100/lib/ionic/js/ionic.bundle.js:29197:26
at completeOutstandingRequest (http://localhost:8100/lib/ionic/js/ionic.bundle.js:18706:10)
at http://localhost:8100/lib/ionic/js/ionic.bundle.js:18978:7
at d (http://localhost:8100/lib/raven-js/dist/raven.min.js:2:4308)
The network logs in chrome show that some requests are cancelled
I am using couchdb version - 1.6.1 and pouchdb version - 5.3.2.
I use following command to replicate dbs:
myDB.replicate.from(remote_db_url,{
live: true,
retry: true,
heartbeat: false
})
Also it would be great if someone can shed some light on heartbeat parameter .
Note: I'm not able to solve the error you describe. Maybe a full stack trace rather than a screenshot might help...
But I will try to shed some light on the heartbeat parameter: Reading the docs already helps a little. See the advanced options for the replicate method:
options.heartbeat: Configure the heartbeat supported by CouchDB which keeps the change connection alive.
So let's look into CouchDB's docs to see what this parameter does:
Networks are a tricky beast, and sometimes you don’t know whether there are no changes coming or your network connection went stale. If you add another query parameter, heartbeat=N, where N is a number, CouchDB will send you a newline character each N milliseconds. As long as you are receiving newline characters, you know there are no new change notifications, but CouchDB is still ready to send you the next one when it occurs.
So basically it seems to be a polling mechanism that sends a message (f.e. a newline) every n milliseconds (where n is the heartbeat value you specify) to make sure the connection between two databases is still working.
Setting the value to false will disable this mechanism.
Regarding the which value can be used for this parameter:
The PouchDB docs further state, that the changes method has a similar parameter described like this:
options.heartbeat: For http adapter only, time in milliseconds for server to give a heartbeat to keep long connections open. Defaults to 10000 (10 seconds), use false to disable the default.
I found there are still failed request when the traffic is high using command like this
haproxy -f /etc/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid)
to hot reload the updated config file.
Here below is the presure testing result using webbench :
/usr/local/bin/webbench -c 10 -t 30 targetHProxyIP:1080
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET targetHProxyIP:1080
10 clients, running 30 sec.
Speed=70586 pages/min, 13372974 bytes/sec.
**Requests: 35289 susceed, 4 failed.**
I run command
haproxy -f /etc/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid)
several times during the pressure testing.
In the haproxy documentation, it mentioned
They will receive the SIGTTOU
611 signal to ask them to temporarily stop listening to the ports so that the new
612 process can grab them
so there is a time period that the old process is not listening on the PORT(say 80) and the new process haven’t start to listen to the PORT (say 80), and during this specific time period, it will cause the NEW connections failed, make sense?
So is there any approach that makes the configuration reload of haproxy that will not impact both existing connections and new connections?
On recent kernels where SO_REUSEPORT is finally implemented (3.9+), this dead period does not exist anymore. While a patch has been available for older kernels for something like 10 years, it's obvious that many users cannot patch their kernels. If your system is more recent, then the new process will succeed its attempt to bind() before asking the previous one to release the port, then there's a period where both processes are bound to the port instead of no process.
There is still a very tiny possibility that a connection arrived in the leaving process' queue at the moment it closes it. There is no reliable way to stop this from happening though.
Update: It looks like ./compute_cluster_for_hadoop.py works with gcutil 1.9.1 but not with gcutil 1.10.0. So what I am really asking is how to fix compute_cluster_for_hadoop to work with the current gcutil.
After using compute_cluster_for_hadoop.py for weeks, now starting a cluster hangs, even after I setup the cluster again.
Here are some things I noticed. First, I now get the following message when I run "compute_cluster_for_hadoop.py start ..." that I have to manually type in "yes" to (Before, it never required any user input).
The authenticity of host
'google-compute-engine-instance;project=cspp53013;zone=us-central1-a;instance=hm;id=9724559583598617300
(8.35.196.11)' can't be established. ECDSA key fingerprint is
02:2b:ea:7d:48:27:7d:1b:e2:2a:d4:44:d0:07:95:b4. Are you sure you want
to continue connecting (yes/no)?
It then proceeds for a while. right after it finishes installing the deb_packages, it prints the following
Processing triggers for ca-certificates ... Updating certificates in
/etc/ssl/certs... 0 added, 0 removed; done. Running hooks in
/etc/ca-certificates/update.d.... done. done.
And then it hangs no matter how long I wait.
Any idea what could have changed or how to fix?
Thanks,
Mike
OK. Figured out the answer. We just have to add
--ssh_arg "-o StrictHostKeyChecking=no"
to line 151 of gce_cluster.py and it works with both gcutil-1.9.1 and gcutil-1.10.0