Documentation
  • INTRODUCTION
  • USERS
    • White Paper
    • Main features of CyberWay
    • Bandwidth differences between EOS and CyberWay
    • Bandwidth implementation
    • How to Launch EOS dApps on CyberWay
    • Glossary
  • DEVELOPMENT ENVIRONMENT
    • Core Concepts
    • 1 Before You Begin
    • 2 Install the CDT
    • 3 Create Development Wallet
    • 4 Start keosd and nodeos
    • 5 Create Test Accounts
  • SOFTWARE MANUALS
    • Core
      • nodeos
      • cleos
      • keosd
      • cyberway.cdt
    • How To Guides
      • How To Ban An Unwanted Account
      • How To Calculate Reward For An Author
      • How To Calculate Reward For A Beneficiary
      • How To Calculate Reward For A Curator
      • How To Create A Wallet
      • How To Create An Account
      • How To Create A Proxy Account
      • How To Create Key Pair
      • How To Delegate Resources
      • How To Deploy A Node Using A Snapshot
      • How To Deploy A Smart Contract
      • How To Get Account Information
      • How To Get Block Information
      • How To Get Transaction Information
      • How To Import A Key
      • How To Link Permission
      • How To List All Key Pair
      • How To Stake Tokens
      • How To Stop A Node Using Docker
      • How To Submit A Proposal For HardFork
      • How To Transfer Tokens To A Worker
      • How To Undelegate Resources
      • How To Unlink Permission
      • How To Unstake Tokens
      • How To Vote
    • API Reference
      • Nodeos Chain API
      • Nodeos Producer API
      • Nodeos Net API
    • Cleos Command Reference
      • Convert
      • Create
      • Get
      • Multisig
      • Net
      • Push
      • Set
      • Sign
      • System
      • Transfer
      • Version
      • Wallet
    • Explorer Command Reference
      • How To Check Your Balance
      • How To Find Out Account ID
      • How To Convert Golos To Golos Power And Vice Versa
      • How To Stake Tokens CYBER
      • How To Transfer Funds From One Account To Another
      • How To Transfer Funds From Pending to Liquid
      • How To Bay Stake
      • How To Withdraw Stake
      • How To Vote For A Validator
      • How To Revoke Your Vote For A Validator
      • How To Bay Vesting Using Explorer
      • How To Vote For A Witness
      • How To Revoke Your Vote For A Witness
  • DEVPORTAL
    • System Contracts
      • BIOS
      • Domain names
      • Govern
      • Multi-Signature
      • Stake
      • Tokens
    • Application Contracts
      • Golos Contracts
        • Charge
        • Control
        • Emission
        • Publication
        • Referral program
        • Social
        • Vesting
        • Memo-keys
        • Determining Rewards for a Post
    • Guide to Creating and Deploying an Application on CyberWay
      • 1 Preliminary Work
      • 2 Creating a Simple Contract
      • 3 Creating Tokens
      • 4 Understanding ABI Files
      • 5 Data Persistence
      • 6 Secondary Indexes
      • 7 Adding Inline Actions
      • 8 Inline Action to External Contract
      • 9 Conclusion
    • The cyberway_wallet designed for the Bittrex market
    • The Event Model
  • VALIDATORS
    • Testnet Installation Guide
      • 1 General
      • 2 Configuring the Docker Image
      • 3 Create Container
      • 4 Connecting to a Node
      • 5 List of Commands Applicable to Any Kind of Container
    • Mainnet Connection Guide
      • Docker-Compose Start-up Instructions
      • APPENDIX A
      • APPENDIX B
    • Golos Blockchain Transit
    • How to join CyberWay for those who are interested in being validators ?
    • Stake Usage Guide
    • Regulations for CyberWay validators. Voting for Validators
Powered by GitBook
On this page
  • Procedure for checking the connection of node to CyberWay Mainnet
  • A1 Monitoring the successful installation
  • A2 Monitoring the start of node synchronization
  • A3 Monitoring the node working state
  • A4 Monitoring the completion of node synchronization
  • Conclusion
  1. VALIDATORS
  2. Mainnet Connection Guide

APPENDIX A

Procedure for checking the connection of node to CyberWay Mainnet

As soon as the start_light.sh script finishes, you have to make sure that docker-composer and services are working properly on your server. Docker-compose logs process information into its internal file. To get and analyze the logged information you can use the following commands:

$ sudo docker logs -f nodeosd
$ sudo docker logs -f mongo

or (to get a partial information)

$ sudo docker logs --tail 100 -f nodeosd
$ sudo docker logs --tail 100 -f mongo

The options: --tail — takes the last lines of text; -f — means that it is necessary to monitor the update log file.

No error messages should be in the logged information.

A1 Monitoring the successful installation

Make sure that the nodeosd and mongo containers are successfully installed. It is recommended to run the following command:

$ sudo docker ps

Containers are considered to be successfully installed if the following conditions are met:

  • no error messages in the log file;

  • the messages about installing containers with the names nodeosd and mongo;

  • the containers are in running state.

A2 Monitoring the start of node synchronization

Make sure that the node has initiated block synchronization. The node is considered to have started this process if the log information contains a piece of text like this one:

info  2019-10-01T00:28:39.752 nodeos    producer_plugin.cpp:339       on_incoming_block    ] Received block d7f859397b3f1220... #1214805 @ 2019-10-01T00:28:36.000 signed by kk5oxqhb2ird [trxs: 0, lib: 1214765, conf: 13, latency: 3752 ms]
info  2019-10-01T00:28:39.771 nodeos    producer_plugin.cpp:339       on_incoming_block    ] Received block 9f560026df0a3394... #1214806 @ 2019-10-01T00:28:39.000 signed by yzpsff4dxom4 [trxs: 0, lib: 1214767, conf: 20, latency: 771 ms]
info  2019-10-01T00:28:42.038 nodeos    producer_plugin.cpp:339       on_incoming_block    ] Received block b2141be6f9c671a3... #1214807 @ 2019-10-01T00:28:42.000 signed by 3ukodagt5qrc [trxs: 0, lib: 1214767, conf: 18, latency: 38 ms]

The start_block field in the text indicates that the node has started processing blocks.

A3 Monitoring the node working state

Node synchronization process can take a long time. Therefore, you should monitor this process from time to time.

Make sure that the node does not hang. To get node status information, you can use the following command:

$ cleos get info

The node is considered to be in working state if the received text contains information about processing head_block_num, like this one:

{
 "server_version": "27be611d",
 "chain_id": "591c8aa5cade588b1ce045d26e5f2a162c52486262bd2d7abcb7fa18247e17ec",
 "head_block_num": 2419294,
 "last_irreversible_block_num": 2419247,
 "last_irreversible_block_id": "0024ea2f63a1e7411b75362def0befaf4698235b17956f3d4ec000491f37d5f8",
 "head_block_id": "0024ea5e6223f4c8c5fadd87e0cb0e5df04cda7aeb9b8c8c9111b56a0e19e665",
 "head_block_time": "2019-11-14T08:17:45.000",
 "head_block_producer": "1avnch3wug2o",
 "virtual_block_cpu_limit": 1400000000,
 "virtual_block_net_limit": 1048576000,
 "block_cpu_limit": 1399900,
 "block_net_limit": 1048576,
 "server_version_string": "v2.0.2-37-g27be611d0"
}

The head_block_num field indicates a current block being processed by the node.

A4 Monitoring the completion of node synchronization

The node is considered to be successfully synchronized if it began to receive blocks. The log file should contain a piece of text like this one:

info  2019-10-01T00:28:39.752 nodeos    producer_plugin.cpp:339       on_incoming_block    ] Received block d7f859397b3f1220... #1214805 @ 2019-10-01T00:28:36.000 signed by kk5oxqhb2ird [trxs: 0, lib: 1214765, conf: 13, latency: 3752 ms]
info  2019-10-01T00:28:39.771 nodeos    producer_plugin.cpp:339       on_incoming_block    ] Received block 9f560026df0a3394... #1214806 @ 2019-10-01T00:28:39.000 signed by yzpsff4dxom4 [trxs: 0, lib: 1214767, conf: 20, latency: 771 ms]
info  2019-10-01T00:28:42.038 nodeos    producer_plugin.cpp:339       on_incoming_block    ] Received block b2141be6f9c671a3... #1214807 @ 2019-10-01T00:28:42.000 signed by 3ukodagt5qrc [trxs: 0, lib: 1214767, conf: 18, latency: 38 ms]

The on_incoming_block field indicates an incoming block being received by the node. Also, make sure that the log file contains information about the latency parameter with time less than 3000 ms.

Conclusion

The node is considered to be successfully synchronized, if the log file contains information similar to the one in this appendix.

PreviousDocker-Compose Start-up InstructionsNextAPPENDIX B

Last updated 5 years ago