A copy of the datadir from @betax or somebody on the minority fork might be useful.  Exclude your config.ini if you are a witness.

i couldnt build graphene since i was on 14.04 trusty and i couldnt install gcc 4.9 in time, had to go to work. WIll get to it later.

Ubuntu 14.04 is our best supported Linux platform, since that is what I use and I am the only core developer who uses Linux almost exclusively.  The compiler I use is

$ g++ --version
g++ (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4


Quote from: Thom on October 11, 2015, 04:25:17 pm

Until now I didn't realize the object_database and genesis.json file location (if it is provided in the config.ini and not the --genesis-json cmd line arg) are relative to the folder from which the witness_node binary is executed.

I made the assumption that everything is relative to the --data-dir folder where the config.ini is found. Although I noticed the genesis.json and object_database were in a different location than the blockchain, config.ini etc, it never occured to me why, since I always launched from the same place each time.

I realize this is a very low priority request, but may I suggest the code be changed to "chroot" (so to speak) the location of all files to the value provided by the --data-dir (-d) command line argument. What would the reason be for not doing that, or not putting the object_database in the same place as the blockchain? Perhaps there is a good reason, but I can't think of any.

I believe it's related to a bug which hasn't been fixed, probably due to low priority.
https://github.com/cryptonomex/graphene/issues/257

The genesis-json location is relative to cwd (where you launch the binary from), because we think about the genesis as being an external input to the system, while the datadir is the internal workings of the system.

The object_database should always be within the data_dir.  I've noticed that sometimes it's created outside the data_dir, but I have not noticed that for a while.  If you have a way to make object_database outside the datadir happen reproducibly, please post in the ticket (if I see it in this thread, I'll post it there, but I don't read every page).

As in BTS 0.x, Graphene allows you to embed a genesis file in the binary.  You can do this with a cmake define of the GRAPHENE_EGENESIS_JSON variable:

cmake -DGRAPHENE_EGENESIS_JSON=path/to/genesis -DCMAKE_BUILD_TYPE=Release .

If you're like me and build in-tree, you may have to purge leftovers of previous builds before running the above command:

make clean
rm -f CMakeCache.txt
find . -name CMakeFiles | xargs rm -Rf

Obviously, you'll have to redefine other cmake settings you use if you purge your cmake files (I use BOOST_ROOT and CMAKE_INSTALL_PREFIX, plus a bunch of Qt-related stuff you probably don't need to worry about right now).

Any witness_node built with egenesis will use the built-in genesis if you don't specify --genesis-json (but you still can in case you want a custom genesis).  Any cli_wallet built like this will have the chain-id of the built-in genesis so you don't have to specify that either.

It may be supicious, but look at it - it is the correct chainID. I do not know why the marque is shown. Have you never seen that? It's just another thing odd about this.

The "NEW CHAIN -- Welcome to graphene!" message should only display:

- If the blockchain is empty
- And --enable-stale-production is set

We do not recommend running with --enable-stale-production except in very specific (and unusual) circumstances:  If you're creating an entirely new blockchain, or if you're trying to resurrect a blockchain which has not had new blocks in a long time (for example if you control a witness for an older testnet that nobody's used for days / weeks and want to resume producing blocks on that testnet for whatever reason).

You might have enable-stale-production set in your config file, if so, I recommend removing it; the banner should go away.

@Spectral @Bhuz

If you guys are having trouble publishing feeds, could you update to latest master and try again?  I made the error message you're getting more informative.

Can't seem to get another instance up and running. I've verified all of the wallets, config and binaries with md5sum to working versions. I've deleted the object_database and blockchain. I've tried --resync-blockchain, --replay-blockchain options. Everytime I start the witness I get this output:

Code: [Select]

2114494ms th_a       application.cpp:712           get_blockchain_synop ] synopsis: ["0000019a905fb92
2c6c7c8e72d1b09c04425e0c1"]
2114531ms th_a       application.cpp:712           get_blockchain_synop ] synopsis: ["0000019a905fb92
2c6c7c8e72d1b09c04425e0c1"]
2118682ms th_a       application.cpp:712           get_blockchain_synop ] synopsis: ["0000019a905fb92
2c6c7c8e72d1b09c04425e0c1","000001a1895e7bb499ff3f12bd5eda0a050488de","000001a4236eb3795a2cfa9c5d9f00177fd0b14c","000001a64a8f85ec0c46910dc9eb8ad1ad6a5d10"]
2118852ms th_a       application.cpp:712           get_blockchain_synop ] synopsis: ["0000019a905fb922c6c7c8e72d1b09c04425e0c1","000001a1895e7bb499ff3f12bd5eda0a050488de","000001a4236eb3795a2cfa9c5d9f00
177fd0b14c","000001a64a8f85ec0c46910dc9eb8ad1ad6a5d10"]

cli_wallet does not show correct "info" at all. Using the same seed as working VPS (104.236.51.238:2005)

How does the info command output look incorrect?  If you are doing --resync-blockchain then it nukes all the downloaded blocks and starts at the beginning, so you will see block times / block numbers in the past until you've finished downloading the chain.  The get_blockchain_synop messages are normal, they show your node exchanging block ID's with peers.

BTW - I still haven't found a way to stop the witness cleanly. The only way I know to stop it at all is with ^C. Sometimes it reports "Aborted ..." in the output but most of the time when it is restarted it complains it was shutdown uncleanly.

Yeah, our shutdown code isn't that robust.  I filed a ticket.

Is there a signal that will do it properly? St least in the old code there was a "quit" command, although it often resulted in a corrupted blockchain database. Can this fundamental issue not be fixed?

SIGINT is your best bet.

When I try to connect the cli_wallet to my local witness node it crashes with the following segfault:

Code: [Select]


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff4f86700 (LWP 7101)]
0x0000000000ed7d98 in websocketpp::processor::hybi13<fc::http::detail::asio_with_stub_log>::consume(unsigned char*, unsigned long, std::error_code&) ()
(gdb) backtrace
#0  0x0000000000ed7d98 in websocketpp::processor::hybi13<fc::http::detail::asio_with_stub_log>::consume(unsigned char*, unsigned long, std::error_code&) ()

All it needs for me is run

Code: [Select]

  ./programs/cli_wallet/cli_wallet -s ws://127.0.0.1:8090  (which gets stuck after wdata.ws_user:  wdata.ws_password:)

Filed as https://github.com/cryptonomex/graphene/issues/365 , seems to be due to upstream https://github.com/zaphoyd/websocketpp/issues/395