6

I am using the latest packaged binaries for Ubuntu - and running Stellar core (not the quick start) - with a connection to a PostgreSQL database. Two questions - 1) How long does it typically take to reach an initial state of synced? I keep checking the info url on my core instance - and it is showing Catching up. It has run for ~20 hours - and a count from the scphistory table shows 114,000+ records (and it keeps growing every few seconds).

2) Why are all of the other tables (other than scphistory) in the core database empty? Outside of a single record in the accounts table, other tables (e.g., trustlines, txhistory, offers, etc.) have 0 rows. Is this normal behavior?

Update, I am seeing this behavior on two different servers (one is a Windows VM in the cloud, and the other a Ubuntu Vm running at home). Having only the scphistory table populated is apparently not normal behavior, and probably points to some problem. Any ideas?

Another Update. After removing/reinstalling the stellar-core package on my Ubuntu VM, I now notice (in the log) that my http listener is not working - "Listening on 0.0.0.0.:11626 for HTTP".

So now I have two problems... Any ideas on how to fix the HTTP listener problem?

A 4th update.... I started over with Ubuntu 16.04, and was able to install the stellar-quickstart package. It started up without any problems, but I see the same behavior. The scphistory table keeps growing, none of the other tables do, and stellar core never reaches a status of synched. Very frustrating. Is anyone out there trying to run the latest version of core - something other than the Docker image?

Improve this question
2
  • You may need to provide additional information. Like version number, configuration file and actual steps so that other people can try to reproduce what you're seeing.
    – MonsieurNicolas
    Commented Aug 9, 2018 at 4:25
  • Hello - to repro....start with a clean Ubuntu image (I used ubuntu-16.04.5-desktop-amd64.iso) - follow the instructions at github.com/stellar/packages#sdf---packages. Implement the "Adding the SDF stable repository to your system" step. Then install the stellar-quickstart package (sudo apt-get stellar-quickstart), and Start it up (sudo systemclt start stellar-core). Make no changes to the any of the .cfg files, etc.. Let it run overnight - query the core db tables and the /info url on stellar-core.
    – tylerc
    Commented Aug 9, 2018 at 13:39

1 Answer 1

Reset to default
5

The default configuration installed by stellar-core-postgres under /etc/stellar/stellar-core.cfg uses CATCHUP_RECENT=1024 so the initial synch should be completed in a few minutes, this is as long as your node is able to successfully connect to another Testnet node which has available open connection slots.

You should be able to track this and other errors in /var/log/stellar/stellar-core.log:

2018-08-10T07:37:49.541 GDFBX [Overlay INFO] successful handshake with [email protected]:11625
...
2018-08-10T07:38:25.099 GDFBX [Ledger INFO] Got consensus: [seq=10470164, prev=88ad9b, tx_count=3, sv: [  txH: a6e5f5, ct: 1533886705, upgrades: [ ] ]]
2018-08-10T07:38:25.099 GDFBX [Ledger INFO] Lost sync, local LCL is 1, network closed ledger 10470164
2018-08-10T07:38:25.099 GDFBX [Ledger INFO] Close of ledger 10470164 buffered, starting catchup
2018-08-10T07:38:25.099 GDFBX [Ledger INFO] Changing state LM_BOOTING_STATE -> LM_CATCHING_UP_STATE
2018-08-10T07:38:25.099 GDFBX [History INFO] Starting catchup with configuration:
  lastClosedLedger: 1
  toLedger: 10470163
  count: 1024
2018-08-10T07:38:25.099 GDFBX [History INFO] Catchup downloading history archive state at checkpoint 10470207
2018-08-10T07:38:25.100 GDFBX [Work WARNING] Scheduling retry #1/5 in 36 sec, for get-history-archive-state

Once successfully connected to a peer (stellar-core-cmd peers), stellar-core buffers SCP history until it has replayed the downloaded history archives from history.stellar.org. This is why the scphistory table is getting populated but none of the others are. During this time you should see 1 account in the accounts table and also a list of known peers in the peers table.

As well as connecting to each other stellar-core nodes also need to be able to retrieve history files from the official history archive, if this is not possible your nodes will not be able to synch/catch up.

A good test would be to run the below command on your nodes to confirm networking is not an issue:

curl -sf http://s3-eu-west-1.amazonaws.com/history.stellar.org/prd/core-testnet/core_testnet_002/history/00/9f/c3/history-009fc33f.json \
-o /var/lib/stellar/buckets/tmp/history-31b2fe0339e22989/stellar-history.json
Improve this answer
2
  • Thanks Tom. I cleared out the buckets folder and reininitialized the DB. It is now working. Not exactly sure what the issue was, perhaps a permissions issue with the bucket folder ( e.g., maybe I was running stellar-core and/or systemctl as myself or root, rather than as stellar, and so files could not be copied).
    – tylerc
    Commented Aug 11, 2018 at 16:07
  • np, could be permissions if you started stellar-core manually as root. The systemd service will run stellar-core as the stellar user so if you manage the service via systemctl you shouldn't encounter the issue again. If you need to wipe the db, you can run sudo -u stellar stellar-core --conf /etc/stellar/stellar-core.cfg --newdb
    – Tom Llewellyn-Smith
    Commented Aug 11, 2018 at 20:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.