No block created at Ethereum on Azure

Question

No block created at Ethereum on Azure

Aoki Nobuaki 61

I set up Parity blockchain network using Ethereum on Azure template sold at market place.
It had worked well before, but suddenly had stopped to create blocks.
For example, when I deployed a contract, no block number was not issued.

There is a warning message (Fallback to `BlockId::Latest) in the log file of Parity.

2020-08-06 08:19:54 UTC IO Worker #1 INFO import 2/25 peers 504 KiB chain 169 MiB db 0 bytes queue 10 KiB sync RPC: 0 conn, 0 req/s, 35 μs
2020-08-06 08:20:24 UTC IO Worker #1 INFO import 2/25 peers 972 KiB chain 169 MiB db 0 bytes queue 10 KiB sync RPC: 0 conn, 0 req/s, 35 μs
2020-08-06 08:20:53 UTC jsonrpc-eventloop-0 WARN parity_rpc::v1::impls::eth Fallback to BlockId::Latest
2020-08-06 08:20:59 UTC IO Worker #1 INFO import 2/25 peers 75 KiB chain 169 MiB db 0 bytes queue 10 KiB sync RPC: 0 conn, 21 req/s, 21 μs
2020-08-06 08:21:29 UTC IO Worker #2 INFO import 2/25 peers 75 KiB chain 169 MiB db 0 bytes queue 10 KiB sync RPC: 0 conn, 5 req/s, 34 μs

Please help me to fix this issue.

AshokPeddakotla-MSFT 10,976 Reputation points

2020-08-24T10:49:32.313+00:00

@Aoki Nobuaki Welcome to Q&A forum.
Sorry to hear that you are facing issues with Ethereum on Azure.
Could you please share the complete logs? You can collect the logs from OMS workspace tab in the portal. Please see Service monitoring for reference.
Aoki Nobuaki 61 Reputation points

2020-08-26T02:33:22.777+00:00

I did not configure to use log analytics, so I cannot collect the logs from OMS workspace.
I attached the parity log file (/var/log/parity/parity.log) which was created in the virtual machine's file system.

At line 3353, the message "Fallback to BlockId::Latest" is written.
At line 3357, the message that transaction is received is written.
At line 3358, the message that transaction is stored to txPool is written.
At lIne 3369, the message that transaction is sent to peers is written.

After that, no block was created.

The date in the logs is different with the fragment of logs I wrote in my question,
but the phenomenon was same that when I sent a transaction,
it was stored to txPool but no block was created.

20334-paritylog-20200805-edit.txt
AshokPeddakotla-MSFT 10,976 Reputation points

2020-08-26T09:40:43.227+00:00

Thanks for sharing the additional details. We are looking into this issue and update you as earliest. Appreciate your time and patience.

AshokPeddakotla-MSFT 10,976 Reputation points

2020-08-24T10:49:32.313+00:00

@Aoki Nobuaki Welcome to Q&A forum.
Sorry to hear that you are facing issues with Ethereum on Azure.
Could you please share the complete logs? You can collect the logs from OMS workspace tab in the portal. Please see Service monitoring for reference.
Aoki Nobuaki 61 Reputation points

2020-08-26T02:33:22.777+00:00

I did not configure to use log analytics, so I cannot collect the logs from OMS workspace.
I attached the parity log file (/var/log/parity/parity.log) which was created in the virtual machine's file system.

At line 3353, the message "Fallback to BlockId::Latest" is written.
At line 3357, the message that transaction is received is written.
At line 3358, the message that transaction is stored to txPool is written.
At lIne 3369, the message that transaction is sent to peers is written.

After that, no block was created.

The date in the logs is different with the fragment of logs I wrote in my question,
but the phenomenon was same that when I sent a transaction,
it was stored to txPool but no block was created.

20334-paritylog-20200805-edit.txt
AshokPeddakotla-MSFT 10,976 Reputation points

2020-08-26T09:40:43.227+00:00

Thanks for sharing the additional details. We are looking into this issue and update you as earliest. Appreciate your time and patience.

Answer 1

Shrc-MSFT 226

Hi, As per the logs shared by you it looks like the node is unable to seal/propose a block. This can happen either if

the validator contract has changed
the node got dropped from list of validators.

Can you please try restarting both the validator Vms in your resource group? This will result in running some setup automatically and might help in resuming mining. Please restart the first VM, once that is up, wait for a few mins and then restart the next VM. This is to ensure there there are no inconsistencies in the blockchain resulting from concurrent restarts.

Aoki Nobuaki 61 Reputation points

2020-08-28T02:55:12.587+00:00

I restarted VMs with 10 minutes intervals, and sent a transaction after 10 minutes of the last vm restat.
But no block is created.

I have more two questions about this restart of VMs.

(a) Does the time interval of VMs restart (a few minutes in the answer) depend on any parameters of Parity nodes, for example, the length of blocks?

(b) After the restart of VMs, how can I check the list of validator nodes is restored correctly?
I understand that the list of validator nodes is hold in a contract, and I don't know how to view it.
Shrc-MSFT 226 Reputation points

2020-09-01T07:22:05.863+00:00

Hi @Aoki Nobuaki

(a) Does the time interval of VMs restart (a few minutes in the answer) depend on any parameters of Parity nodes, for example, the length of blocks - No it doesn't. We recommend that to prevent simultaneous restarts of validators that can cause forks.

(b) After the restart of VMs, how can I check the list of validator nodes is restored correctly? - The parity version running in these nodes use validator contracts and does not explicitly list validators. You can try updating the contract using this link https://openethereum.github.io/wiki/Validator-Set-Tutorial-2 in case it has gotten corrupted.
Aoki Nobuaki 61 Reputation points

2020-09-18T07:03:09.477+00:00

The blockchain nodes cannot create a new block, so I cannot update the validator set contract.

By the way, I modified the spec.json file to specify the validator address (selected from the account addresses of nodes) directly to the validators.list attribute,
and after restarting docker containers, I could deploy a contarct the nodes.

When I got the validator addresses by calling getValidators function of the validator set contract.
there were an address which was not in the account addresses of the nodes.
Does the addresses which validator set contract manages match always to the account addressed of the nodes?

And It seems that the account addresses are re-created after the boot of virtual machines,
and I guess this could be the cause of the no-block-creation problem,
and the problem could be recurred again if I restart virtual machines.
How can I restart them safely?
Shrc-MSFT 226 Reputation points

2020-09-29T12:48:57.037+00:00

Hi @Aoki Nobuaki

The rc.local config has been setup to bring up the poa network post restart with same validator address. So restart will not impact the account addresses. in your specific case, the additional address you may be seeing can be a old validator that was probably not removed from the network as mining was halted earlier. In case your block mining, transactions etc. are not impacted, you can ignore it.
Aoki Nobuaki 61 Reputation points

2020-10-02T00:57:54.797+00:00

II understand that restart of VM will not impact the account address.
Blocks are now created by modifying the addresses of validator nodes in spec.json.
I will see how it goes for a while.

Thank you.

No block created at Ethereum on Azure

0 additional answers

Activity