Merge pull request #751 from mDuo13/server_wont_sync

Server Won't Sync troubleshooting page
This commit is contained in:
Rome Reginelli
2020-01-13 17:21:12 -08:00
committed by GitHub
23 changed files with 226 additions and 32 deletions

View File

@@ -1,4 +1,4 @@
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
2018-Jan-24 01:11:07 HTTPClient:NFO Connecting to 127.0.0.1:5005
{

View File

@@ -1,4 +1,4 @@
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
2018-Jan-24 01:17:54 HTTPClient:NFO Connecting to 127.0.0.1:5005
{

View File

@@ -1,4 +1,4 @@
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
2018-Apr-03 00:09:53 HTTPClient:NFO Connecting to 127.0.0.1:5005
{

View File

@@ -1,4 +1,4 @@
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
2018-Mar-21 21:00:05 HTTPClient:NFO Connecting to 127.0.0.1:5005
{

View File

@@ -1,4 +1,4 @@
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
2018-Jan-24 01:11:07 HTTPClient:NFO Connecting to 127.0.0.1:5005
{

View File

@@ -1,4 +1,4 @@
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
2018-Jan-24 01:17:54 HTTPClient:NFO Connecting to 127.0.0.1:5005
{

View File

@@ -1,4 +1,4 @@
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
2018-Apr-03 00:10:30 HTTPClient:NFO Connecting to 127.0.0.1:5005
{

View File

@@ -1,4 +1,4 @@
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
2018-Mar-28 01:52:49 HTTPClient:NFO Connecting to 127.0.0.1:5005
{

View File

@@ -1,4 +1,4 @@
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
2018-Jan-24 01:11:53 HTTPClient:NFO Connecting to 127.0.0.1:5005
{

View File

@@ -1,4 +1,4 @@
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
2018-Jan-24 01:18:39 HTTPClient:NFO Connecting to 127.0.0.1:5005
{

View File

@@ -1,4 +1,4 @@
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
2018-Apr-03 00:11:17 HTTPClient:NFO Connecting to 127.0.0.1:5005
{

View File

@@ -1,4 +1,4 @@
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
2018-Mar-28 02:17:55 HTTPClient:NFO Connecting to 127.0.0.1:5005
{

View File

@@ -24,6 +24,7 @@
[Marker]: markers-and-pagination.html
[マーカー]: markers-and-pagination.html
[node public key]: peer-protocol.html#node-key-pair
[node key pair]: peer-protocol.html#node-key-pair
[peer reservation]: peer-protocol.html#fixed-peers-and-peer-reservations
[peer reservations]: peer-protocol.html#fixed-peers-and-peer-reservations
[result code]: transaction-results.html

View File

@@ -11,6 +11,18 @@ XRP Ledgerのサーバーは、XRP LedgerピアプロトコルRTXPを使
ピアツーピア接続を確立するには、サーバーどうしをHTTPSで接続し、一方のサーバーはRTXPへの切り替えのために[HTTPアップグレード](https://tools.ietf.org/html/rfc7230#section-6.7)を要求します。(詳細は、[`rippled`リポジトリ](https://github.com/ripple/rippled)の[Overlay Network](https://github.com/ripple/rippled/blob/906ef761bab95f80b0a7e0cab3b4c594b226cf57/src/ripple/overlay/README.md#handshake)を参照してください。)
## ピア発見
**Note:** この部分は日本語ではまだ利用できません。助けたいと思うなら、[提供して下さい!](https://github.com/ripple/xrpl-dev-portal#contributing)
The XRP Ledger uses a "gossip" protocol to help find servers find others to connect to in the XRP Ledger network. Whenever a server starts up, it reconnects to any other peers it previously connected to. As a fallback, it uses the [hardcoded public hubs](https://github.com/ripple/rippled/blob/fa57859477441b60914e6239382c6fba286a0c26/src/ripple/overlay/impl/OverlayImpl.cpp#L518-L525). After a server successfully connects to a peer, it asks that peer for the contact information (generally, IP address and port) of other XRP Ledger servers that may also be seeking peers. The server can then connect to those servers, and ask them for the contact information of yet more XRP Ledger servers to peer with. Through this process, the server establishes enough peer connections that it can remain reliably connected to the rest of the network even if it loses a connection to any single peer.
Typically, a server needs to connect to a public hub only once, for a short amount of time, to find other peers. After doing so, the server may or may not remain connected to the hub, depending on how stable its network connection is, how busy the hub is, and how many other high-quality peers the server finds. The server saves the addresses of these other peers so it can try reconnecting directly to those peers later, after a network outage or a restart.
The [peers method][] shows a list of peers your server is currently connected to.
For certain high-value servers (such as important [validators](rippled-server-modes.html)) you may prefer not to have your server connect to untrusted peers through the peer discovery process. In this case, you can configure your server to use [private peers](#プライベートピア) only.
## ピアプロトコルポート
XRP Ledgerに参加するため、`rippled`サーバーはピアプロトコルを使用して任意のピアに接続します。(すべてのピアは、現行サーバーで[クラスター化されている](clustering.html)場合を除き、信頼できないものとして扱われます。)

View File

@@ -119,11 +119,24 @@ Each member of the `validator_sites` field array is an object with the following
| `Field` | Type | Description |
|:-----------------------|:-----------------|:--------------------------------|
| `last_refresh_status` | String | If present, the[`ListDisposition`](https://github.com/ripple/rippled/blob/master/src/ripple/app/misc/ValidatorList.h) of the most recent refresh of the site. If missing, the site has not yet been succesfully queried. |
| `last_refresh_time` | String | Human readable time when the site was last queried. If missing, the site has not yet been succesfully queried. |
| `last_refresh_status` | String | If present, shows the status of the most recent refresh of the site. If missing, the site has not yet been successfully queried. See **Site Status Values** below for possible states and their meanings. |
| `last_refresh_time` | String | Human readable time when the site was last queried. If missing, the site has not yet been successfully queried. |
| `refresh_interval_min` | Unsigned Integer | The number of minutes between refresh attempts. |
| `uri` | String | The URI of the site. |
#### Site Status Values
The `last_refresh_status` field can have the following values:
| Value | Meaning |
|:----------------------|:-----------------------------------------------------|
| `accepted` | The site provided a valid list, which your server is now using. |
| `same_sequence` | The site provided a list with the same sequence number as your existing list, so your server continued using its existing list. |
| `unsupported_version` | The site provided a list, but your server does not support the list format version number in the list. You might need to [update `rippled`](install-rippled.html) to a newer software version. |
| `untrusted` | The site provided a list from the site that is signed by a cryptographic keypair your server is not configured to trust. You may want to check for typos in your `validators.txt` file and check to see if the list publisher changed their cryptographic keys. |
| `stale` | The site provided a list with a lower sequence number than the list your server is already using. |
| `invalid` | The site provided a list or signature that was not validly formed. |
### Possible Errors
* Any of the [universal error types][].

View File

@@ -34,7 +34,7 @@
複数のXRP LedgerキーセットアドレスとシークレットをSignerListのメンバーに追加する必要があります。SignerListには、レジャーに既存の資金供給のあるアドレス、または[wallet_proposeメソッド][]で生成した新しいアドレスを追加できます。例:
$ rippled wallet_propose
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
@@ -88,7 +88,7 @@
> }
> ]
> }'
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
@@ -143,7 +143,7 @@
スタンドアロンモードで`rippled`を実行している場合は、[ledger_acceptメソッド][]を使用してレジャーを手動で閉鎖します。
$ rippled ledger_accept
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
@@ -160,7 +160,7 @@
通常、アカウントは異なるタイプのオブジェクトトラストラインやオファーなどを複数所有できます。このチュートリアルで新しいアドレスに資金を供給した場合、SignerListが応答の唯一のオブジェクトになります。
$ rippled account_objects rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC validated
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {

View File

@@ -31,7 +31,7 @@ You need one or more validly-formed XRP Ledger addresses to include as members o
You can generate new addresses using the [wallet_propose method][]. For example:
$ rippled wallet_propose
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
@@ -85,7 +85,7 @@ In this example, the SignerList has 3 members, with the weights and quorum set u
> }
> ]
> }'
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
@@ -145,7 +145,7 @@ Use the [account_objects method][] to confirm that the SignerList is associated
Normally, an account can own many objects of different types (such as trust lines and offers). If you funded a new address for this tutorial, the SignerList is the only object in the response.
$ rippled account_objects rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC validated
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {

View File

@@ -123,7 +123,7 @@ Ripple社は、推奨される一連のバリデータを記載した[バリデ
- [公開ハブ](#公開ハブを使用した接続)
- [プロキシ](#プロキシを使用した接続)
これらのいずれかの構成を使用すると、[DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack)攻撃からバリデータを保護するとともに、ネットワークへの信頼できる接続をバリデータに提供する上で役立ちます。
これらのいずれかの構成を使用すると、[DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack)攻撃からバリデータを保護するとともに、ネットワークへの信頼できる接続をバリデータに提供する上で役立ちます。
### 公開ハブを使用した接続

View File

@@ -21,6 +21,49 @@ For troubleshooting purposes, the most important fields are (from most commonly
- If your server remains in the `connected` state for hours, or returns to the `connected` state after being in the `full` or `proposing` states, that usually indicates that your server cannot keep up with the rest of the network. The most common bottlenecks are disk I/O, network bandwidth, and RAM.
- For example, the following server state information shows a healthy server that took less than 3 minutes to sync (split between the `disconnected`, `connected`, and `syncing` states), and is currently in the fully-synced `proposing` state, where it has remained for approximately 90 minutes:
$ ./rippled server_info
Loading: "/etc/opt/ripple/rippled.cfg"
2020-Jan-03 22:49:32.834134358 HTTPClient:NFO Connecting to 127.0.0.1:5005
{
"result" : {
"info" : {
... (trimmed) ...
"server_state" : "proposing",
"server_state_duration_us" : "5183282365",
"state_accounting" : {
"connected" : {
"duration_us" : "126164786",
"transitions" : 1
},
"disconnected" : {
"duration_us" : "2111321",
"transitions" : 1
},
"full" : {
"duration_us" : "5183282365",
"transitions" : 1
},
"syncing" : {
"duration_us" : "5545604",
"transitions" : 1
},
"tracking" : {
"duration_us" : "0",
"transitions" : 1
}
},
... (trimmed) ...
}
}
}
If your server shows multiple `transitions` between the same states, that indicates that your server was unable to stay synced. If you do not have a `full` or `proposing` state, then your server has not yet synced to the network. Over a long period of time, it's likely your server may occasionally lose sync because internet connections fluctuate, so this is only a problem if the amount of time spent not in sync is a significant portion of your uptime. After about 24 hours of uptime, if less than 99% of your server's total runtime is spent in the `full` or `proposing` states, you may want to investigate possible sources of instability.
- For help debugging syncing issues, see [Server Doesn't Sync](server-doesnt-sync.html).
- **`complete_ledgers`** - This field shows which [ledger indexes](basic-data-types.html#ledger-index) your server has complete ledger data for. Healthy servers usually have a single range of recent ledgers, such as `"12133424-12133858"`.
- If you have a disjoint set of complete ledgers such as `"11845721-12133420,12133424-12133858"`, that could indicate that your server has had intermittent outages or has temporarily fallen out of sync with the rest of the network. The most common causes for this are insufficient disk I/O or network bandwidth.

View File

@@ -0,0 +1,112 @@
# rippled Server Doesn't Sync
This page explains possible reasons [a `rippled` server](the-rippled-server.html) may start successfully, but get stuck in a ["connected" state](rippled-server-states.html) without ever fully connecting to the network. (If the server crashes during or shortly after startup, see [Server Won't Start](server-wont-start.html) instead.)
These instructions assume you have [installed `rippled`](install-rippled.html) on a supported platform.
## Normal Syncing Behavior
Syncing with the network normally takes about 5 to 15 minutes. During that time, the server does several things:
- Loads a recommended validator list (typically from `vl.ripple.com`) to determine which validators it trusts.
- [Discovers peer servers](peer-protocol.html#peer-discovery) and connects to them.
- Downloads the [header](ledger-header.html) and full [state information](ledgers.html#tree-format) of the latest ledger from its peers, and uses that to build its internal database of ledger data.
- Listens to its trusted validators to find which ledger hashes have been recently validated.
- Collects newly-broadcast transactions and attempts to apply them to its in-progress ledger.
If the server is unable to keep up with the network while doing these tasks, the server does not sync to the network.
## First Step: Restart
Many syncing issues can be resolved by restarting the server. No matter why it failed to sync the first time, it may succeed on the second try.
If the [server_info method][] shows a [`server_state`](rippled-server-states.html) other than `proposing` or `full` and a `server_state_duration_us` of more than `900000000` (15 minutes in microseconds), then you should shut down the `rippled` service, wait a few seconds, and start it again. Optionally, restart the entire machine.
If the problem persists, check the other possibilities listed on this page. If none of them seem to apply, [open an issue in the `rippled` repository](https://github.com/ripple/rippled/issues) and add the "Syncing issue" label.
## Usual Causes of Syncing Issues
The most common cause of syncing issues is not meeting the [system requirements](system-requirements.html). The three most common shortfalls are:
- **Slow disks.** You need a consistently fast solid state disk (SSD). Cloud providers like AWS usually don't guarantee disk performance, which may be impacted by other users of shared hardware.
- **Insufficient RAM.** The memory requirements vary depending on several factors including ones that are hard to predict like network load and how people use the XRP Ledger, so it's good to have more than the minimum system requirements just in case.
- **Poor network connection.** Network requirements vary the most based on how people use the XRP Ledger, but a slow or unstable connection can make it impossible to keep up with new transactions and data added to the XRP Ledger.
If you are having trouble remaining synced, double-check that your server meets the system requirements. Depending on how you use your server, you may need to meet the higher "Recommended" requirements instead of just the "Minimum" requirements. If you meet the "Recommended" requirements and still cannot sync, try the other possibilities on this page.
## Couldn't Load Validator List
The default configuration uses a recommended list of validators retrieved from `vl.ripple.com`. This list is signed by Ripple's cryptographic key pair and has a built-in expiration date. If your server cannot download the list from `vl.ripple.com` for some reason, your server does not choose a set of trusted validators and cannot determine which possible ledgers to declare as valid. (If you are connected to [the testnet or another parallel network](parallel-networks.html), your server uses a list of trusted validators for that network instead.)
The `validator_list` block in the [server_info method][] response shows the status of your validator list including its expiration date. If you have a list, but it's expired, it's possible that your server had connectivity to the validator list site before but hasn't been able to connect lately, so your current list expired while your server was unable to download a more updated list.
You can also use the [validator_list_sites method][] to get more detailed information. If the `last_refresh_status` and `last_refresh_time` fields are missing from the validator site objects in the response, that probably indicates that your server is having trouble connecting to the validator list site. Check your firewall configuration to make sure you're not blocking outgoing traffic on port 80 (HTTP) or 443 (HTTPS). Also check that your DNS is able to resolve the domain of your validator list site.
<!-- TODO: create a tutorial for how to sideload a validator list from file and link it here -->
## Not Enough Peers
If your server does not connect to enough [peer servers](peer-protocol.html), it may not be able to download enough data to remain synced with the network as the network continues processing new transactions. This can happen if your network connection is unreliable, or if you configure your server as a [private server](peer-protocol.html#private-peers) without adding enough reliable fixed peers.
Use the [peers method][] to get information about your server's current peers. If you have exactly 10 or 11 peers, that may indicate that your firewall is blocking incoming peer connections. [Set up port forwarding](forward-ports-for-peering.html) to allow more incoming connections. If your server is configured as a private server, double-check the contents and syntax of the `[ips_fixed]` stanza in your config file, and add more proxies or public hubs if possible.
## Corrupt Databases
In rare cases, corrupt data saved in your `rippled` server's internal databases could cause it to fail to sync. You can safely delete your server's databases in most circumstances as long as the server is not running. Corrupt data can be the result of a momentary hardware failure when copying or writing to disk, a more serious disk failure, a different process crashing and writing to the wrong part of the disk, or other issues.
As a test, you can temporarily change the paths to your server's databases as long as you have enough free space to re-download the current ledger and store other settings.
**Note:** When you change the database paths, the server does not load some saved settings, such as the server's current [node key pair][] and [peer reservations](peer-protocol.html#fixed-peers-and-peer-reservations). If changing the database paths fixes your server' syncing problems, you may want to re-create some of these settings.
1. Stop the `rippled` server if it is running.
$ sudo systemctl stop rippled
2. Create new empty folders to hold the fresh databases.
$ mkdir /var/lib/rippled/db_new/
$ mkdir /var/lib/rippled/db_new/nudb
3. Edit the config file to use the new paths. Be sure to change the `path` field of the `[node_db]` stanza **and** the value of the `[database_path]` stanza.
[node_db]
type=NuDB
path=/var/lib/rippled/db_new/nudb
[database_path]
/var/lib/rippled/db_new
{% include '_snippets/conf-file-location.md' %}<!--_ -->
4. Start the `rippled` server again.
$ sudo systemctl start rippled
If the server successfully syncs using the fresh databases, you can delete the folders that hold the old databases. You may also want to check for hardware failures, especially to your disk and RAM.
## See Also
- **Concepts:**
- [The `rippled` Server](the-rippled-server.html)
- [Peer Protocol](peer-protocol.html)
- [Technical FAQ](technical-faq.html)
- **Tutorials:**
- [Understanding Log Messages](understanding-log-messages.html)
- [Capacity Planning](capacity-planning.html)
- **References:**
- [rippled API Reference](rippled-api.html)
- [peers method][]
- [server_info method][]
- [validator_list_sites method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

View File

@@ -54,7 +54,7 @@ SlignerListのメンバーの1人のシークレットキーとアドレスを
> "SigningPubKey":"",
> "Fee":"30000"
> }'
Loading:"/home/mduo13/.config/ripple/rippled.cfg"
Loading:"/etc/opt/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" :{
@@ -123,7 +123,7 @@ SlignerListのメンバーの1人のシークレットキーとアドレスを
> "TransactionType" :"TrustSet",
> "hash" :"A94A6417D1A7AAB059822B894E13D322ED3712F7212CE9257801F96DE6C3F6AE"
> }'
Loading:"/home/mduo13/.config/ripple/rippled.cfg"
Loading:"/etc/opt/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" :{
@@ -201,7 +201,7 @@ SlignerListのメンバーの1人のシークレットキーとアドレスを
> "TransactionType" :"TrustSet",
> "hash" :"BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6"
> }'
Loading:"/home/mduo13/.config/ripple/rippled.cfg"
Loading:"/etc/opt/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result":{
@@ -251,7 +251,7 @@ SlignerListのメンバーの1人のシークレットキーとアドレスを
スタンドアロンモードで`rippled`を実行している場合は、[ledger_acceptメソッド][]を使用してレジャーを手動で閉鎖します。
$ rippled ledger_accept
Loading:"/home/mduo13/.config/ripple/rippled.cfg"
Loading:"/etc/opt/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" :{
@@ -270,7 +270,7 @@ SlignerListのメンバーの1人のシークレットキーとアドレスを
スタンドアロンモードでは、サーバーは手動で閉鎖されたレジャーを自動的に`validated`とみなします。
$ rippled tx BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6
Loading:"/home/mduo13/.config/ripple/rippled.cfg"
Loading:"/etc/opt/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result":{

View File

@@ -54,7 +54,7 @@ Use the [sign_for method][] with the secret key and address of one of the member
> "SigningPubKey": "",
> "Fee": "30000"
> }'
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
@@ -123,7 +123,7 @@ You can collect additional signatures in parallel or in serial:
> "TransactionType" : "TrustSet",
> "hash" : "A94A6417D1A7AAB059822B894E13D322ED3712F7212CE9257801F96DE6C3F6AE"
> }'
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
@@ -201,7 +201,7 @@ If you collected the signatures in parallel, you must manually construct a `tx_j
> "TransactionType" : "TrustSet",
> "hash" : "BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6"
> }'
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result": {
@@ -251,7 +251,7 @@ If you are using the live network, you can wait 4-7 seconds for the ledger to cl
If you're running `rippled` in stand-alone mode, use the [ledger_accept method][] to manually close the ledger:
$ rippled ledger_accept
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
@@ -270,7 +270,7 @@ On the live network, you must also confirm that the `validated` field is set to
In stand-alone mode, the server automatically considers a ledger to be `validated` if it has been manually closed.
$ rippled tx BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Loading: "/etc/opt/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result": {

View File

@@ -276,6 +276,8 @@ targets:
"peer-protocol.html#node-key-pair": "peer-protocol.html#ノードキーペア"
"run-rippled-as-a-validator.html#connect-using-proxies": "run-rippled-as-a-validator.html#プロキシを使用した接続"
"rippled-server-modes.html#public-hubs": "rippled-server-modes.html#公開ハブ"
"peer-protocol.html#peer-discovery": "peer-protocol.html#ピア発見"
"ledgers.html#tree-format": "ledgers.html#ツリーの形式"
- name: xrp-api-only
@@ -2727,6 +2729,17 @@ pages:
targets:
- ja
- md: tutorials/manage-the-rippled-server/troubleshooting/server-doesnt-sync.md
html: server-doesnt-sync.html
funnel: Docs
doc_type: Tutorials
category: Manage the rippled Server
subcategory: Troubleshooting rippled
blurb: Troubleshoot problems that make a rippled server unable to sync with the rest of the XRP Ledger.
targets:
- en
- ja
- md: tutorials/manage-the-rippled-server/troubleshooting/server-wont-start.md
html: server-wont-start.html
funnel: Docs