Author Topic: October 5 Test Network  (Read 127070 times)

0 Members and 1 Guest are viewing this topic.

Offline svk

Could be it's using the built in genesis which only has 10 or so accounts in it.

 Did you triplecheck the genesis file is in the right location? ;) and are you using a seed node in config.ini?

Yes on all counts. I posted the full config.ini below (above).

Sorry missed that post. Try commenting out the p2p-endpoint line, I remember that was preventing me from connecting to the testnet when we first launched it.

Tbh I used to run using config.ini but now I just set everything in the command line, much easier to reproduce...

I launch like this, with the genesis file in the same directory, works every time:

Code: [Select]
./witness_node --rpc-endpoint "127.0.0.1:8090"  --genesis-json oct5-genesis.json -d oct-5 -s "104.236.51.238:2005"
Worker: dev.bitsharesblocks

Offline Thom

Could be it's using the built in genesis which only has 10 or so accounts in it.

 Did you triplecheck the genesis file is in the right location? ;) and are you using a seed node in config.ini?

Yes on all counts. I posted the full config.ini below (above).
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline Thom

I can't explain it.
There are probably others who can help you better than me... and I'm one of those who compile and run from source.

..but what comes to mind is that you said that the paths must be relative to the binary. Do you see the same problem if you place the genesis file together with the binary, and specify datadir as a simple directory name? Could there be a problem with OS permissions?

What happens if you don't specify the datadir at all?

First, I didn't say "the paths must be relative to the binary", I said they must be relative to where the binary is launched. The object_database marks the folder from which the binary is launched. My binaries reside in a totally different folder than where I launch them from.

If I don't specify a datadir at all it will create the witness_node_data_dir and place a config.ini "template" in it along with the blockchain, logs and p2p folders.

If I launch it from some other folder here's what happens:

Quote
admin@seed08:~/BitShares2$ mkdir ../test
admin@seed08:~/BitShares2$ cd ../test/
admin@seed08:~/test$ witness_node --genesis-json /home/admin/BitShares2/oct5-genesis.json
1877558ms th_a       main.cpp:120                  main                 ] Writing new config file at /home/admin/test/witness_node_data_dir/config.ini
1877560ms th_a       witness.cpp:83                plugin_initialize    ] witness plugin:  plugin_initialize() begin
1877561ms th_a       witness.cpp:93                plugin_initialize    ] key_id_to_wif_pair: ["GPH6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV","5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3"]
1877561ms th_a       witness.cpp:111               plugin_initialize    ] witness plugin:  plugin_initialize() end
1877561ms th_a       db_management.cpp:131         open                 ] Old database version detected, reindex is required
1877561ms th_a       db_management.cpp:98          wipe                 ] Wiping database
1877574ms th_a       object_database.cpp:81        wipe                 ] Wiping object_database.
1877574ms th_a       application.cpp:243           operator()           ] Initializing database...
1914624ms th_a       db_debug.cpp:79               debug_dump           ] total_balances[asset_id_type()].value: 14239376866944 core_asset_data.current_supply.value: 271289987694689
1914624ms th_a       db_debug.cpp:82               debug_dump           ] core_in_orders: 14239376866944 reported_core_in_orders: 14239376866944
1914706ms th_a       thread.cpp:95                 thread               ] name:ntp tid:140160123512576
1914721ms th_a       thread.cpp:95                 thread               ] name:p2p tid:140160087664384

1914729ms th_a       application.cpp:135           reset_p2p_node       ] Configured p2p node to listen on 0.0.0.0:49818
1914732ms th_a       witness.cpp:116               plugin_startup       ] witness plugin:  plugin_startup() begin

1914733ms th_a       witness.cpp:133               plugin_startup       ] No witnesses configured! Please add witness IDs and private keys to configuration.
1914733ms th_a       witness.cpp:134               plugin_startup       ] witness plugin:  plugin_startup() end
1914734ms th_a       main.cpp:167                  main                 ] Started witness node on a chain with 0 blocks.
1914734ms th_a       main.cpp:168                  main                 ] Chain ID is 60e21871125ea9995fe498b7f68a87a85c6583725ea5448f6fd969c59a37df83
1915008ms ntp        ntp.cpp:177                   read_loop            ] ntp_delta_time updated to -3504 us

Notice the chainID? It is correct now. Weird things going on related to that config file!
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline svk

Could be it's using the built in genesis which only has 10 or so accounts in it.

 Did you triplecheck the genesis file is in the right location? ;) and are you using a seed node in config.ini?
Worker: dev.bitsharesblocks

Offline Thom

That invalid log in config error always happens btw, you can safely ignore it.

Good to know. I thought maybe it might indicate a deeper problem, so glad that isn't the case.

I'm not seeing the genesis file open in the strace output, but clearly it opened it if it determined the timestamp in it was wrong, and I've seen errors reported many times when the file can't be found.

Here's the complete output:
Code: [Select]
admin@seed08:~/BitShares2$ strace -f witness_node --data-dir /home/admin/BitShares2 --genesis-json /home/admin/BitShares2/oct5-genesis.[58/1850]
 | grep open                                                                                                                                               
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/librt.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libreadline.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libncurses.so.5", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/x86_64-linux-gnu/libstdc++.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/ssl/openssl.cnf", O_RDONLY) = 3
open("/home/admin/BitShares2/config.ini", O_RDONLY) = 3
open("/home/admin/BitShares2/config.ini", O_RDONLY) = 3
openat(AT_FDCWD, "/home/admin/BitShares2/blockchain", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/home/admin/BitShares2/blockchain/db_version", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/2", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/3", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/4", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/5", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/6", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/7", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/8", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/10", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/11", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/12", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/13", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/14", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/15", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/0", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/1", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/3", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/4", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/5", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/6", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/7", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/8", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/9", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/10", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/11", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/12", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/13", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/5/1", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/database/block_num_to_block/index", O_RDWR) = 3
open("/home/admin/BitShares2/blockchain/database/block_num_to_block/blocks", O_RDWR) = 4
[pid  2358] open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 9
[pid  2358] open("/lib/x86_64-linux-gnu/tls/x86_64/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  2358] open("/lib/x86_64-linux-gnu/tls/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  2358] open("/lib/x86_64-linux-gnu/x86_64/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  2358] open("/lib/x86_64-linux-gnu/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  2358] open("/usr/lib/x86_64-linux-gnu/tls/x86_64/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  2358] open("/usr/lib/x86_64-linux-gnu/tls/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  2358] open("/usr/lib/x86_64-linux-gnu/x86_64/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  2358] open("/usr/lib/x86_64-linux-gnu/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  2358] open("/lib/tls/x86_64/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  2358] open("/lib/tls/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  2358] open("/lib/x86_64/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  2358] open("/lib/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  2358] open("/usr/lib/tls/x86_64/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  2358] open("/usr/lib/tls/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  2358] open("/usr/lib/x86_64/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  2358] open("/usr/lib/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  2358] open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid  2358] <... open resumed> )        = 10
[pid  2358] open("/lib/x86_64-linux-gnu/libswift.so", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid  2358] <... open resumed> )        = -1 ENOENT (No such file or directory)
[pid  2362] open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 9
[pid  2362] open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 9
[pid  2362] open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 9
[pid  2358] open("/usr/lib/x86_64-linux-gnu/libswift.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  2358] open("/lib/libswift.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  2358] open("/usr/lib/libswift.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  2362] open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid  2362] <... open resumed> )        = 9
[pid  2362] open("/lib/x86_64-linux-gnu/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 9
[pid  2362] open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 9
[pid  2362] open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 9
[pid  2362] open("/lib/x86_64-linux-gnu/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = 9
[pid  2362] open("/lib/x86_64-linux-gnu/libresolv.so.2", O_RDONLY|O_CLOEXEC) = 9
[pid  2358] open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid  2358] <... open resumed> )        = 9
[pid  2362] open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid  2362] <... open resumed> )        = 10
[pid  2358] open("/lib/x86_64-linux-gnu/libnfhwcrhk.so", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid  2358] <... open resumed> )        = -1 ENOENT (No such file or directory)
[pid  2358] open("/usr/lib/x86_64-linux-gnu/libnfhwcrhk.so", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid  2358] <... open resumed> )        = -1 ENOENT (No such file or directory)
[pid  2358] open("/lib/libnfhwcrhk.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  2358] open("/usr/lib/libnfhwcrhk.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  2358] open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 9
[pid  2358] open("/lib/x86_64-linux-gnu/libSureWareHook.so", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid  2358] <... open resumed> )        = -1 ENOENT (No such file or directory)
[pid  2358] open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 10
[pid  2361] open("/home/admin/BitShares2/p2p/node_config.json", O_RDONLY) = 10
[pid  2361] open("/home/admin/BitShares2/p2p/peers.json", O_RDONLY) = 10
[pid  2362] open("/etc/gai.conf", O_RDONLY|O_CLOEXEC) = 9
[pid  2361] open("/home/admin/BitShares2/p2p/node_config.json", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 10
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline svk

That invalid log in config error always happens btw, you can safely ignore it.
Worker: dev.bitsharesblocks

Offline Thom

sometimes it is helpful to see what files are opened or atempted to open  using strace

Code: [Select]
strace -f ./witness_node_startup_script   2>&1 | grep open

Thanks for that jtme. I haven't been real heavy into coding for years so I'm quite out of practice and my memory isn't what it used to be, so tips like this are greatly appreciated. I could compare the output if that on my troublesome VPS to one that works and see if the libs are the same for example. Here's what it produced up to the point of opening the blockchain:

Code: [Select]
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/librt.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libreadline.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libncurses.so.5", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/x86_64-linux-gnu/libstdc++.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/ssl/openssl.cnf", O_RDONLY) = 3
open("/home/admin/BitShares2/config.ini", O_RDONLY) = 3
open("/home/admin/BitShares2/config.ini", O_RDONLY) = 3
openat(AT_FDCWD, "/home/admin/BitShares2/blockchain", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/home/admin/BitShares2/blockchain/db_version", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/2", O_RDONLY) = 3

I looked at the main.cpp of the code and noticed one boost method is used which is related to the config file logging error, so I reinstalled boost again but it didn't matter.
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline jtme

I've been launching the witness_node the same way for several months and never ran into issues like you had, both building locally and copying to a VPS. One thing that did bug me a few times was an incorrect genesis path, that error message really is unclear...

Yeah that one bit me in the ass so hard I still can't sit without pain :)

It was changed from a relative path that processed ~ for example to an absolute one.

sometimes it is helpful to see what files are opened or atempted to open  using strace

Code: [Select]
strace -f ./witness_node_startup_script   2>&1 | grep open

Offline Thom

I've been launching the witness_node the same way for several months and never ran into issues like you had, both building locally and copying to a VPS. One thing that did bug me a few times was an incorrect genesis path, that error message really is unclear...

Yeah that one bit me in the ass so hard I still can't sit without pain :)

It was changed from a relative path that processed ~ for example to an absolute one.
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline Thom

@svk:

Code: [Select]
#Endpoint for P2P node to listen on
p2p-endpoint = 0.0.0.0:1776

# P2P nodes to connect to on startup (may specify multiple times)
#seed-node = 45.55.6.216:1776
#seed-node = 114.92.254.159:62015
seed-node = 104.236.51.238:2005

# Pairs of [BLOCK_NUM,BLOCK_ID] that should be enforced as checkpoints.
# checkpoint =

# ChainID

# Endpoint for websocket RPC to listen on
rpc-endpoint = 127.0.0.1:8090

# Endpoint for TLS websocket RPC to listen on
# rpc-tls-endpoint =

# The TLS certificate file for this server
# server-pem =

# Password for this certificate                                             
# server-pem-password =

# File to read Genesis State from
genesis-json = oct5-genesis.json
#genesis-json = oct-05-testnet-genesis.json
#genesis-json = oct-02-testnet-genesis.json
#genesis-json = aug-14-test-genesis.json
#genesis-json = aug-19-puppies-test-genesis.json

# JSON file specifying API permissions
# api-access =

# Enable block production, even if the chain is stale.
enable-stale-production = true

# Percent of witnesses (0-99) that must be participating in order to produce blocks
required-participation = false

# Allow block production, even if the last block was produced by the same witness.
allow-consecutive = false

# ID of witness controlled by this node (e.g. "1.6.0", quotes are required, may specify multiple times)
witness-id = "1.6.34"

# Tuple of [PublicKey, WIF private key] (may specify multiple times)
private-key = [ "GPH1", "..." ]
private-key = [ "GPH2", "..." ]
private-key = [ "GPH", "..." ]

# Account ID to track history for (may specify multiple times)
# track-account =

# Track market history by grouping orders into buckets of equal size measured in seconds specified as a JSON array of numbers
bucket-size = [15,60,300,3600,86400]

# How far back in time to track history for each bucket size, measured in the number of buckets (default: 1000)
history-per-size = 1000

# declare an appender named "stderr" that writes messages to the console
[log.console_appender.stderr]
stream=std_error

# declare an appender named "p2p" that writes messages to p2p.log
[log.file_appender.p2p]
filename=logs/p2p/p2p.log
# filename can be absolute or relative to this config file

# route any messages logged to the default logger to the "stderr" logger we
# declared above, if they are info level are higher
[logger.default]
level=info
appenders=stderr

# route messages sent to the "p2p" logger to the p2p appender declared above
[logger.p2p]
level=debug
appenders=p2p


As I said, this was copied and verified from another VPS which is running just fine.
« Last Edit: October 11, 2015, 06:31:46 pm by Thom »
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline Spectral

I can't explain it.
There are probably others who can help you better than me... and I'm one of those who compile and run from source.

..but what comes to mind is that you said that the paths must be relative to the binary. Do you see the same problem if you place the genesis file together with the binary, and specify datadir as a simple directory name? Could there be a problem with OS permissions?

What happens if you don't specify the datadir at all?
Vote for BTS-2 witness: spectral (1.6.30)
0.9 DVS delegate: dvs1.bitspace
Stay tuned for bitspace-clains worker!

Offline svk

I made the assumption that everything is relative to the --data-dir folder where the config.ini is found.

Now that you mention it, I noticed a config.ini in this directory:
/graphene/witness_node_data_dir

Is this a template that is used automatically when a new data directory is created? Can it be used to keep a default config.ini that will be copied at first startup?

@spectral: As roadscape says, the witness_node_data_dir is the default folder if you don't specify one with -d or --data-dir on the command line. It will put an empty (more or less, it could be considered a template I guess) config.ini in that folder. I don't know about most of the witnesses here, but since I'm not building the code on the VPS that runs it I only move the executable binaries to the VPS; I do not use the graphene/programs/witness_node folder structure, which is probably why I am having so many difficulties, tho that shouldn't matter.

However I have discovered things still are changing related to the basic command line / config file processing that require I verify many things to be certain I haven't made a silly mistake. I am constantly going back and forth between using automation scripts to launch and launching directly on the command line to investigate the behavior I see. Like this for example:

  • witness_node and cli_wallet binaries are in the path (only 1 version in path).
  • all files confirmed the same as working witness node with md5sum.
  • known good config.ini and oct5-genesis.json in ~BitShares2 folder.
  • cd BitShares2 and run the following:
  • witness_node --data-dir /home/admin/BitShares2 --genesis-json /home/admin/BitShares2/oct5-genesis.json

Produces this output:

Quote
admin@seed08:~/BitShares2$ witness_node --data-dir /home/admin/BitShares2 --genesis-json /home/admin/BitShares2             
2374823ms th_a       main.cpp:115                  main                 ] Error parsing logging config from config file /home/admin/BitShares2/config.ini, using default config
2374823ms th_a       witness.cpp:83                plugin_initialize    ] witness plugin:  plugin_initialize() begin
2374824ms th_a       witness.cpp:93                plugin_initialize    ] key_id_to_wif_pair: ["GPH1...","5K..."]
2374824ms th_a       witness.cpp:93                plugin_initialize    ] key_id_to_wif_pair: ["GPH2...","5K..."]
2374824ms th_a       witness.cpp:93                plugin_initialize    ] key_id_to_wif_pair: ["GPH3...","5K..."]
2374824ms th_a       witness.cpp:111               plugin_initialize    ] witness plugin:  plugin_initialize() end
2385370ms th_a       thread.cpp:95                 thread               ] name:ntp tid:139919911945984
2385372ms th_a       thread.cpp:95                 thread               ] name[emoji14]2p tid:139919825561344

2385400ms th_a       application.cpp:123           reset_p2p_node       ] Adding seed node 104.236.51.238:2005
2385402ms th_a       application.cpp:135           reset_p2p_node       ] Configured p2p node to listen on 0.0.0.0:1776
2385403ms th_a       application.cpp:185           reset_websocket_serv ] Configured websocket rpc to listen on 127.0.0.1:8090
2385404ms th_a       witness.cpp:116               plugin_startup       ] witness plugin:  plugin_startup() begin
2385404ms th_a       witness.cpp:123               plugin_startup       ] Launching block production for 1 witnesses.

********************************
*                                                            *
*   --------- NEW CHAIN --------  *
*   - Welcome to Graphene! -  *
*   ------------------------------------   *
*                                                            *
********************************

Your genesis seems to have an old timestamp
Please consider using the --genesis-timestamp option to give your genesis a recent timestamp

2385406ms th_a       witness.cpp:134               plugin_startup       ] witness plugin:  plugin_startup() end
2385407ms th_a       main.cpp:167                  main                 ] Started witness node on a chain with 0 blocks.
2385408ms th_a       main.cpp:168                  main                 ] Chain ID is 9f8faf7d8e4919364d1a14169bb1ac4c0ec8001929f8dbee1026d3a54b298b81
2385507ms ntp        ntp.cpp:177                   read_loop            ] ntp_delta_time updated to 5344 us
2623923ms asio       main.cpp:163                  operator()           ] Caught ^C attempting to exit cleanly

I can't explain it. The following questions come to mind:

  • Why does it report "Error parsing logging config from config file" with a verified copy of a known good config.ini in use on another VPS?
  • If it is using a default config as it says, where is it coming up with the seed, the 3 private-key pairs, witness-id and other values?
  • If it can read the genesis.json file to determine the timestamp is old, why does it have the wrong chainID?

I am trying to get a reproducible installation script to establish the VPS platform to run graphene, but it is proving to be quite time consuming and rather difficult. I know there may be some variations in the OS image for "Ubuntu 14.04" each VPS company provides, but I wouldn't think they would impact the run time operation of the code in the ways I observe. If the binaries don't run at all or produce immediate errors perhaps a package wasn't installed or is the wrong version, but I wouldn't attribute output like the above to missing dependencies or subtle OS differences.

At this stage of development I wouldn't expect to see this type of "anomolous" behavior. I don't know if others observe it too and just don't mention it here or they don't see these things because they continue to use the same exact environment everytime.  I post these "reports" not only to find answers but also b/c that's what I thought this thread is all about. If I'm missing something right in front of my nose I hope somebody can point it our to me.
Hard to say without also seeing your config.json. Do you have a seed nodes specified in there? If not you need one..

I've been launching the witness_node the same way for several months and never ran into issues like you had, both building locally and copying to a VPS. One thing that did bug me a few times was an incorrect genesis path, that error message really is unclear...
Worker: dev.bitsharesblocks

Offline Thom

I made the assumption that everything is relative to the --data-dir folder where the config.ini is found.

Now that you mention it, I noticed a config.ini in this directory:
/graphene/witness_node_data_dir

Is this a template that is used automatically when a new data directory is created? Can it be used to keep a default config.ini that will be copied at first startup?

@spectral: As roadscape says, the witness_node_data_dir is the default folder if you don't specify one with -d or --data-dir on the command line. It will put an empty (more or less, it could be considered a template I guess) config.ini in that folder. I don't know about most of the witnesses here, but since I'm not building the code on the VPS that runs it I only move the executable binaries to the VPS; I do not use the graphene/programs/witness_node folder structure, which is probably why I am having so many difficulties, tho that shouldn't matter.

However I have discovered things still are changing related to the basic command line / config file processing that require I verify many things to be certain I haven't made a silly mistake. I am constantly going back and forth between using automation scripts to launch and launching directly on the command line to investigate the behavior I see. Like this for example:

  • witness_node and cli_wallet binaries are in the path (only 1 version in path).
  • all files confirmed the same as working witness node with md5sum.
  • known good config.ini and oct5-genesis.json in ~BitShares2 folder.
  • cd BitShares2 and run the following:
  • witness_node --data-dir /home/admin/BitShares2 --genesis-json /home/admin/BitShares2/oct5-genesis.json

Produces this output:

Quote
admin@seed08:~/BitShares2$ witness_node --data-dir /home/admin/BitShares2 --genesis-json /home/admin/BitShares2             
2374823ms th_a       main.cpp:115                  main                 ] Error parsing logging config from config file /home/admin/BitShares2/config.ini, using default config
2374823ms th_a       witness.cpp:83                plugin_initialize    ] witness plugin:  plugin_initialize() begin
2374824ms th_a       witness.cpp:93                plugin_initialize    ] key_id_to_wif_pair: ["GPH1...","5K..."]
2374824ms th_a       witness.cpp:93                plugin_initialize    ] key_id_to_wif_pair: ["GPH2...","5K..."]
2374824ms th_a       witness.cpp:93                plugin_initialize    ] key_id_to_wif_pair: ["GPH3...","5K..."]
2374824ms th_a       witness.cpp:111               plugin_initialize    ] witness plugin:  plugin_initialize() end
2385370ms th_a       thread.cpp:95                 thread               ] name:ntp tid:139919911945984
2385372ms th_a       thread.cpp:95                 thread               ] name:p2p tid:139919825561344

2385400ms th_a       application.cpp:123           reset_p2p_node       ] Adding seed node 104.236.51.238:2005
2385402ms th_a       application.cpp:135           reset_p2p_node       ] Configured p2p node to listen on 0.0.0.0:1776
2385403ms th_a       application.cpp:185           reset_websocket_serv ] Configured websocket rpc to listen on 127.0.0.1:8090
2385404ms th_a       witness.cpp:116               plugin_startup       ] witness plugin:  plugin_startup() begin
2385404ms th_a       witness.cpp:123               plugin_startup       ] Launching block production for 1 witnesses.

********************************
*                                                            *
*   --------- NEW CHAIN --------  *
*   - Welcome to Graphene! -  *
*   ------------------------------------   *
*                                                            *
********************************

Your genesis seems to have an old timestamp
Please consider using the --genesis-timestamp option to give your genesis a recent timestamp

2385406ms th_a       witness.cpp:134               plugin_startup       ] witness plugin:  plugin_startup() end
2385407ms th_a       main.cpp:167                  main                 ] Started witness node on a chain with 0 blocks.
2385408ms th_a       main.cpp:168                  main                 ] Chain ID is 9f8faf7d8e4919364d1a14169bb1ac4c0ec8001929f8dbee1026d3a54b298b81
2385507ms ntp        ntp.cpp:177                   read_loop            ] ntp_delta_time updated to 5344 us
2623923ms asio       main.cpp:163                  operator()           ] Caught ^C attempting to exit cleanly

I can't explain it. The following questions come to mind:

  • Why does it report "Error parsing logging config from config file" with a verified copy of a known good config.ini in use on another VPS?
  • If it is using a default config as it says, where is it coming up with the seed, the 3 private-key pairs, witness-id and other values?
  • If it can read the genesis.json file to determine the timestamp is old, why does it have the wrong chainID?

I am trying to get a reproducible installation script to establish the VPS platform to run graphene, but it is proving to be quite time consuming and rather difficult. I know there may be some variations in the OS image for "Ubuntu 14.04" each VPS company provides, but I wouldn't think they would impact the run time operation of the code in the ways I observe. If the binaries don't run at all or produce immediate errors perhaps a package wasn't installed or is the wrong version, but I wouldn't attribute output like the above to missing dependencies or subtle OS differences.

At this stage of development I wouldn't expect to see this type of "anomolous" behavior. I don't know if others observe it too and just don't mention it here or they don't see these things because they continue to use the same exact environment everytime.  I post these "reports" not only to find answers but also b/c that's what I thought this thread is all about. If I'm missing something right in front of my nose I hope somebody can point it our to me.





« Last Edit: October 11, 2015, 06:13:05 pm by Thom »
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline roadscape

I made the assumption that everything is relative to the --data-dir folder where the config.ini is found.

Now that you mention it, I noticed a config.ini in this directory:
/graphene/witness_node_data_dir

Is this a template that is used automatically when a new data directory is created? Can it be used to keep a default config.ini that will be copied at first startup?

witness_node_data_dir is created when you don't specify a --data-dir.. i.e., not a template, just a default data dir name
http://cryptofresh.com  |  witness: roadscape

Offline Spectral

I made the assumption that everything is relative to the --data-dir folder where the config.ini is found.

Now that you mention it, I noticed a config.ini in this directory:
/graphene/witness_node_data_dir

Is this a template that is used automatically when a new data directory is created? Can it be used to keep a default config.ini that will be copied at first startup?
Vote for BTS-2 witness: spectral (1.6.30)
0.9 DVS delegate: dvs1.bitspace
Stay tuned for bitspace-clains worker!