Update Japanese translation files

This commit is contained in:
mDuo13
2020-06-05 17:21:18 -07:00
parent 5d47d4f288
commit fcad9d0376
110 changed files with 9094 additions and 2955 deletions

View File

@@ -14,29 +14,71 @@
rippled server_info
```
このコマンドに対する応答には大量の情報が含まれています。これについては、[server_infoメソッド][]で説明します。
トラブルシューティングで最も重要なフィールドは以下のとおりです(最も一般的に使われるものから順に説明します)。
このコマンドに対する応答には大量の情報が含まれています。これについては、[server_infoメソッド][]で説明します。トラブルシューティングで最も重要なフィールドは以下のとおりです(最も一般的に使われるものから順に説明します)。
- **`server_state`** - ほとんどの場合、このフィールドには`proposing`[バリデータとして設定されている](run-rippled-as-a-validator.html)サーバーの場合)または `full`(バリデータではないサーバーの場合)が表示されます。値が`connected`の場合は、サーバーはピアツーピアネットワークの他の部分と通信できますが、共有レジャーの状態を追跡するのに十分なデータがありません。通常、レジャーの残りの部分の状態を同期するには起動後515分かかります。
- サーバーが数時間にわたり`connected`状態である場合、または`full`あるいは`proposing`状態になってから`connected`状態に戻る場合は通常、サーバーがネットワークの他の部分よりも遅れています。最も一般的なボトルネックはディスクI/O、ネットワーク帯域幅、RAMです。
- **`server_state`** - ほとんどの場合、このフィールドには`proposing`[バリデータとして設定されている](run-rippled-as-a-validator.html)サーバーの場合)または`full`(バリデータではないサーバーの場合)が表示されます。値が`connected`の場合は、サーバーはピアツーピアネットワークの他の部分と通信できますが、共有レジャーの状態を追跡するのに十分なデータがありません。通常、レジャーの残りの部分の状態を同期するには起動後515分かかります。
- サーバーが数時間にわたり`connected`状態である場合、または`full`あるいは`proposing`状態になってから`connected`状態に戻る場合は通常、サーバーがネットワークの他の部分よりも遅れています。最も一般的なボトルネックはディスクI/O、ネットワーク帯域幅、RAMです。
- 例えば、以下のサーバー状態情報は、正常なサーバーで同期が3分以内に完了しており`disconnected``connected``syncing`の状態に分かれている)、現在は完全に同期された`proposing`状態が約90分間続いていることを示しています。
$ ./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" : {
...(省略)...
"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
}
},
...(省略)...
}
}
}
サーバーが同じ状態間で複数の`transitions`を示している場合、サーバーが同期状態を維持できなかったことを示します。`full`または`proposing`状態でない場合、サーバーはまだネットワークに同期されていません。長期の間には、インターネット接続が不安定になってサーバーの同期が時々失われる場合があります。そのためこれが問題になるのは、同期されていない時間がアップタイムのかなりの部分を占める場合のみです。アップタイムが約24時間経過した後に、`full`または`proposing`状態だった時間がサーバーの合計実行時間の99%に満たない場合、不安定になっている原因を調査することをお勧めします。
- 同期の問題をデバッグする際の参考として、[サーバーが同期しない](server-doesnt-sync.html)を参照してください。
- **`complete_ledgers`** - このフィールドは、サーバーに完全なレジャーデータが保管されている[レジャーインデックス](basic-data-types.html#レジャーインデックス)を示します。通常、正常なサーバーには連続した最新のレジャーのセット(`"12133424-12133858"`など)があります。
- 連続していない完全なレジャーのセット(`"11845721-12133420,12133424-12133858"`などがある場合、サーバーで断続的な障害が発生したか、またはネットワークの他の部分との同期が一時的にできなかった可能性があります。このようなケースの最も一般的な原因は、ディスクI/Oまたはネットワーク帯域幅の不足です。
- 通常、`rippled`サーバーはピアから最新のレジャー履歴をダウンロードします。レジャー履歴のギャップが数時間以上続く場合は、欠落データを所有しているピアに接続されていない可能性があります。この状況が発生した場合は、構成ファイルに次のスタンザを追加して再起動すれば、完全な履歴が保管されているRippleのパブリックサーバーの1つにサーバーを強制的にピア接続できます。
[ips_fixed]
s2.ripple.com 51235
- 連続していない完全なレジャーのセット(`"11845721-12133420,12133424-12133858"`などがある場合、サーバーで断続的な障害が発生したか、またはネットワークの他の部分との同期が一時的にできなかった可能性があります。このようなケースの最も一般的な原因は、ディスクI/Oまたはネットワーク帯域幅の不足です。
- 通常、`rippled`サーバーはピアから最新のレジャー履歴をダウンロードします。レジャー履歴のギャップが数時間以上続く場合は、欠落データを所有しているピアに接続されていない可能性があります。この状況が発生した場合は、構成ファイルに次のスタンザを追加して再起動すれば、完全な履歴が保管されているRippleのパブリックサーバーの1つにサーバーを強制的にピア接続できます。
[ips_fixed]
s2.ripple.com 51235
- **`amendment_blocked`** - このフィールドは通常`server_info`応答では省略されます。このフィールドの値が`true`の場合は、ネットワークにより承認された[Amendment](amendments.html)がサーバーに導入されていません。ほとんどの場合は、最新バージョンに[rippledを更新する](install-rippled.html)ことで修正できます。また[featureメソッド][]を使用して、現在有効なAmendment ID、サーバーでサポートされているAmendment ID、サーバーでサポートされていないAmendment IDを確認することもできます。
- **`peers`** - このフィールドは、サーバーが接続しているXRP Ledgerピアツーピアネットワーク内のその他のサーバーの数を示します。特定のピアのみに接続するように明示的に構成されているサーバーを除き、正常なサーバーでは通常550ピアと表示されます。
- ピアの数が0の場合、サーバーがネットワークに接続できないか、またはシステムクロックが正しくない可能性があります。サーバーのクロックを同期するため、すべてのサーバーで[NTP](http://www.ntp.org/)デーモンを実行することが推奨されます。)
- ピアの数が10の場合、`rippled`が[NAT](https://en.wikipedia.org/wiki/Network_address_translation)を使用したルーター経由での着信接続を受信できていない可能性があります。接続を改善するには、ルーターのファイアウォールがピアツーピア接続に使用するポート([デフォルトでは](https://github.com/ripple/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/cfg/rippled-example.cfg#L1065)ポート51235を転送するように設定します。
- ピアの数が0の場合、サーバーがネットワークに接続できないか、またはシステムクロックが正しくない可能性があります。サーバーのクロックを同期するため、すべてのサーバーで[NTP](http://www.ntp.org/)デーモンを実行することが推奨されます。)
- ピアの数が10の場合、`rippled`が[NAT](https://en.wikipedia.org/wiki/Network_address_translation)を使用したルーター経由での着信接続を受信できていない可能性があります。接続を改善するには、ルーターのファイアウォールがピアツーピア接続に使用するポート([デフォルトでは](https://github.com/ripple/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/cfg/rippled-example.cfg#L1065)ポート51235を転送するように設定します。
### サーバーから応答がない場合
@@ -44,10 +86,10 @@ rippled server_info
```json
{
"error" : "internal",
"error_code" : 71,
"error_message" : "Internal error.",
"error_what" : "no response from server"
"error" : "internal",
"error_code" : 71,
"error_message" : "Internal error.",
"error_what" : "no response from server"
}
```
@@ -57,7 +99,6 @@ rippled server_info
- サーバーに接続するために異なる[パラメーターを`rippled`コマンドラインクライアントに](commandline-usage.html#クライアントモードのオプション)渡す必要があります。
- `rippled`サーバーがJSON-RPC接続を受け入れるように構成されていない可能性があります。
## サーバーログの確認
[デフォルトでは](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg#L1139-L1142)`rippled`はサーバーのデバッグログを`/var/log/rippled/debug.log`ファイルに書き込みます。このデバッグログの位置は、サーバーの構成ファイルにより異なる可能性があります。`rippled`サービスを(`systemctl`または`service`を使用して開始するのではなく)直接開始した場合、デフォルトではログメッセージはコンソールにも出力されます。
@@ -68,7 +109,19 @@ rippled server_info
さまざまな種類のログメッセージに関する詳しい説明については、[ログメッセージについて](understanding-log-messages.html)を参照してください。
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](the-rippled-server.html)
- [Amendment](amendments.html)
- **チュートリアル:**
- [容量の計画](capacity-planning.html)
- [rippledの構成](configure-rippled.html)
- **リファレンス:**
- [rippled APIリファレンス](rippled-api.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [log_levelメソッド][]
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

View File

@@ -0,0 +1,109 @@
# rippledサーバーが同期しない
このページでは、[`rippled`サーバー](the-rippled-server.html)が正常に起動したのに、ネットワークに完全に接続できずに[「connected」状態](rippled-server-states.html)のままになっている場合の原因について説明します。(サーバーが起動中または起動直後にクラッシュした場合は、[サーバーが起動しない](server-wont-start.html)を参照してください。)
以下の手順では、サポートされているプラットフォームに[`rippled`がインストール](install-rippled.html)されていることを前提としています。
## 通常の同期動作
ネットワークとの同期は、通常はおよそ5分から15分で完了します。その間に、サーバーは次のようなさまざまなことを行います。
- 推奨バリデータリストを読み込み(通常は`vl.ripple.com`から)、信頼できるバリデータを判断します。
- [ピアサーバーを検出](peer-protocol.html#ピア発見)して接続します。
- ピアから最新のレジャーの[ヘッダー](ledger-header.html)と完全な[状態情報](ledgers.html#ツリーの形式)をダウンロードし、それを使用してレジャーデータの内部データベースを構築します。
- 信頼できるバリデータをリッスンして、最近検証されたレジャーハッシュを見つけます。
- 新たにブロードキャストされたトランザクションを収集し、それを進行中のレジャーに適用します。
サーバーがこれらのタスクを行うときにネットワークに同調して対応できなかった場合は、サーバーはネットワークと同期しない状態になります。
## 最初のステップ: 再起動
多くの同期の問題は、サーバーを再起動することで解決できます。最初に同期が失敗した原因がどのようなものであっても、2回目では成功する場合があります。
[server_infoメソッド][]で[`server_state`](rippled-server-states.html)が`proposing`または`full`以外の状態であると示され、`server_state_duration_us``900000000`15分のマイクロ秒表記より大きい場合は、`rippled`サービスをシャットダウンしてから数秒間待ち、再起動してください。場合によっては、マシン全体を再起動します。
問題が解決しない場合は、このページに記載されている他の原因を確認してください。いずれも当てはまらないと思われる場合は、[`rippled`リポジトリに問題を登録](https://github.com/ripple/rippled/issues)し、「Syncing issue」ラベルを追加します。
## 同期の問題のよくある原因
同期の問題の原因として最もよくあるのは、[システム要件](system-requirements.html)を満たしていないことです。要件を満たせない主な原因は次の3つです。
- **低速なディスク。** 安定して高速な性能を発揮するソリッドステートディスクSSDが必要です。AWSなどのクラウドプロバイダーはディスク性能を保証しておらず、ハードウェアを共有する他のユーザーの影響を受ける可能性があります。
- **不十分なRAM。** メモリー要件はさまざまな要因に大きく左右されます。例えば、ネットワークの負荷やXRP Ledgerがどのように使われるかなど、予測しづらい要因もあるため、念のため最小システム要件よりも大きいメモリーを用意することをお勧めします。
- **品質の悪いネットワーク接続。** ネットワーク要件は、主にXRP Ledgerをユーザーがどのよう使うかによって左右されますが、接続が低速または不安定な場合、XRP Ledgerに追加された新しいトランザクションやデータとの同期がとれなくなる可能性があります。
同期の問題が解消されない場合は、サーバーがシステム要件を満たしているかもう一度確認してください。サーバーの使用方法によっては、「最小」要件よりも高い「推奨」要件を満たす必要があります。「推奨」要件を満たしていても、まだ同期ができない場合は、このページの他の原因を試してみてください。
## バリデータリストを読み込めない
デフォルトの構成では、`vl.ripple.com`から受信した推奨バリデータリストを使用します。このリストは、Rippleの暗号鍵ペアで署名されており、有効期限が組み込まれています。サーバーが何らかの理由でリストを`vl.ripple.com`からダウンロードできない場合、サーバーは信頼できるバリデータのセットを選択せず、有効として宣言できるレジャーを決定できません。([Testnetや別の並列ネットワーク](parallel-networks.html)に接続している場合、サーバーは代わりにそのネットワークの信頼できるバリデータのリストを使用します。)
[server_infoメソッド][]応答の`validator_list`ブロックは、バリデータリストの有効期限などのステータスを示します。リストがあるが期限切れである場合、サーバーは以前はそのバリデータリストのサイトに接続できていたものの、その後接続できなくなった可能性があります。その場合、現在のリストはサーバーがそれより新しいリストをダウンロードできなかったために期限切れとなった可能性があります。
また、[validator_list_sitesメソッド][]を使用して、より詳細な情報を取得することもできます。応答内のバリデータサイトオブジェクトに`last_refresh_status`および`last_refresh_time`フィールドがない場合、サーバーからバリデータリストのサイトへの接続に問題があることを示しています。ファイアウォールの設定をチェックして、ポート80HTTPまたは443HTTPSの発信トラフィックをブロックしていないことを確認してください。また、DNSがバリデータリストのサイトのドメインを解決できることも確認してください。
<!-- TODO: create a tutorial for how to sideload a validator list from file and link it here -->
## 十分な数のピアがない
サーバーが十分な数の[ピアサーバー](peer-protocol.html)に接続していない場合、サーバーは十分なデータをダウンロードできず、ネットワークが新しいトランザクションを処理するときに同期がとれなくなる可能性があります。この問題は、ネットワーク接続の信頼性が低い場合や、十分な数の信頼できる固定ピアを追加せずにサーバーを[プライベートサーバー](peer-protocol.html#プライベートピア)として構成している場合に起こる可能性があります。
[peersメソッド][]を使用して、サーバーの現在のピアについての情報を取得します。ピアの数が10または11の場合、ファイアウォールが着信ピア接続をブロックしていることを示しています。[ポートフォワーディングを設定](forward-ports-for-peering.html)して、より多くの着信接続を許可します。サーバーがプライベートサーバーとして構成されている場合は、構成ファイルの`[ips_fixed]`スタンザの内容と構文を再度確認し、可能であればプロキシと公開ハブをさらに追加します。
## データベースの破損
まれに、`rippled`サーバーの内部データベースに保存されているデータが破損していることで同期の問題が発生する場合があります。サーバーが稼動中でなければ、ほとんどの場合、サーバーのデータベースを安全に削除できます。データの破損は、ディスクにコピーまたは書き込みするときに起こった一時的なハードウェア障害や、より深刻なディスク障害、別のプロセスがクラッシュしてディスクの誤った部分に書き込んだなど、さまざまな問題の結果として起こる可能性があります。
テストとして、十分な空き容量があれば、サーバーのデータベースへのパスを一時的に変更することで、現行のレジャーをダウンロードし直して、別の設定を保存できます。
**注記:** データベースのパスを変更した場合、サーバーはサーバーの現在の[ノードキーペア][]や[ピアリザベーション](peer-protocol.html#固定ピアとピアリザベーション)など、保存されている一部の設定を読み込めません。データベースのパスを変更することでサーバーの同期の問題が解決した場合は、これらの設定の一部を再作成することをお勧めします。
1. `rippled`サーバーが稼働中の場合は停止します。
$ sudo systemctl stop rippled
2. 新しいデータベースを格納するための新しい空のフォルダーを作成します。
$ mkdir /var/lib/rippled/db_new/
$ mkdir /var/lib/rippled/db_new/nudb
3. 新しいパスを使用するように構成ファイルを編集します。`[node_db]`スタンザの`path`フィールド**と**`[database_path]`スタンザの値を変更します。
[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. `rippled`サーバーを再起動します。
$ sudo systemctl start rippled
新しいデータベースを使用してサーバーが同期に成功したら、以前のデータベースを格納していたフォルダーを削除できます。また、ハードウェア障害、特にディスクとRAMの障害を確認することもお勧めします。
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](the-rippled-server.html)
- [ピアプロトコル](peer-protocol.html)
- [技術に関するよくある質問](technical-faq.html)
- **チュートリアル:**
- [ログメッセージについて](understanding-log-messages.html)
- [容量の計画](capacity-planning.html)
- **リファレンス:**
- [rippled APIリファレンス](rippled-api.html)
- [peersメソッド][]
- [server_infoメソッド][]
- [validator_list_sitesメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

View File

@@ -1,46 +1,45 @@
# rippledサーバーが起動しない
このページでは、`rippled`サーバーが起動しない際に考えられる原因とその修正方法を説明します。
このページでは、[`rippled`サーバー](the-rippled-server.html)が起動しない際に考えられる原因とその修正方法を説明します。
以下の手順では、サポートされているプラットフォームに[`rippled`がインストール](install-rippled.html)されていることを前提としています。
## ファイル記述子の制限
一部のLinuxバリアントでは、`rippled`を実行しようとすると以下のようなエラーメッセージが出力されることがあります。
```テキスト
```text
WARNING: There are only 1024 file descriptors (soft limit) available, which
limit the number of simultaneous connections.
```
これは、セキュリティの点からシステムで1つのプロセスが開くことができるファイルの数に制限があるが、その制限が`rippled`にとっては少なすぎる場合に発生します。この問題を修正するには、**ルートアクセス権限が必要です**。以下の手順に従い、`rippled`が開くことができるファイルの数を増やします。
1. 次の行を`/etc/security/limits.conf` ファイルの終わりに追加します。
1. 次の行を`/etc/security/limits.conf`ファイルの終わりに追加します。
* soft nofile 65536
* hard nofile 65536
2. [開くことができるファイルの数のハード制限](https://ss64.com/bash/ulimit.html)が現在`65536`であることを確認します。
ulimit -Hn
このコマンドの出力は`65536`になるはずです。
このコマンドの出力は`65536`になるはずです。
3. `rippled`をもう一度起動します。
systemctl start rippled
4. それでも`rippled`が起動しない場合は、`/etc/sysctl.conf`を開き、以下のカーネルレベル設定を付加します。
fs.file-max = 65536
## /etc/opt/ripple/rippled.cfgを開くことができない
`rippled` が起動時にクラッシュし、以下のようなエラーが出力される場合は、`rippled`が構成ファイルを読み取ることができません。
`rippled`が起動時にクラッシュし、以下のようなエラーが出力される場合は、`rippled`が構成ファイルを読み取ることができません。
```テキスト
```text
Loading: "/etc/opt/ripple/rippled.cfg"
Failed to open '"/etc/opt/ripple/rippled.cfg"'.
Terminating thread rippled: main: unhandled St13runtime_error 'Can not create "/var/opt/ripple"'
@@ -52,16 +51,16 @@ Aborted (core dumped)
- 構成ファイル(デフォルトのロケーションは`/etc/opt/ripple/rippled.cfg`)が存在しており、`rippled`プロセスを実行するユーザー(通常は`rippled`)にこのファイルの読み取り権限があることを確認します。
- `rippled`ユーザーが読み取ることができる構成ファイルを`$HOME/.config/ripple/rippled.cfg`に作成します(`$HOME``rippled`ユーザーのホームディレクトリを指しています)。
**ヒント:** `rippled`リポジトリには、RPMのインストール時にデフォルトの構成として提供される[`rippled.cfg`サンプルファイル](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg)が含まれています。このファイルがない場合は、上記のリンク先からコピーできます。
**ヒント:**`rippled`リポジトリには、RPMのインストール時にデフォルトの構成として提供される[`rippled.cfg`サンプルファイル](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg)が含まれています。このファイルがない場合は、上記のリンク先からコピーできます。
- `--conf` [コマンドラインオプション](commandline-usage.html)を使用して、使用する構成ファイルのパスを指定します。
- `--conf`[コマンドラインオプション](commandline-usage.html)を使用して、使用する構成ファイルのパスを指定します。
## バリデータファイルを開くことができない
`rippled`が起動時にクラッシュし、以下のようなエラーが出力される場合は、`rippled`はプライマリ構成ファイルを読み取ることはできても、この構成ファイルに指定されている別のバリデータ構成ファイル(通常は`validators.txt`)を読み取ることができません。
```テキスト
```text
Loading: "/home/rippled/.config/ripple/rippled.cfg"
Terminating thread rippled: main: unhandled St13runtime_error 'The file specified in [validators_file] does not exist: /home/rippled/.config/ripple/validators.txt'
Aborted (core dumped)
@@ -70,19 +69,19 @@ Aborted (core dumped)
考えられる解決策:
- `[validators.txt]`ファイルが存在し、`rippled`ユーザーにこのファイルの読み取り権限があることを確認します。
**ヒント:**`rippled`リポジトリには、RPMのインストール時にデフォルトの構成として提供される[`validators.txt`サンプルファイル](https://github.com/ripple/rippled/blob/master/cfg/validators-example.txt)が含まれています。このファイルがない場合は、上記のリンク先からコピーできます。
**ヒント:** `rippled`リポジトリには、RPMのインストール時にデフォルトの構成として提供される[`validators.txt`サンプルファイル](https://github.com/ripple/rippled/blob/master/cfg/validators-example.txt)が含まれています。このファイルがない場合は、上記のリンク先からコピーできます。
- `rippled.cfg`ファイルを編集し、`[validators_file]`設定を変更して、`validators.txt`ファイル(またはこれに相当するファイル)の正しいパスを指定します。ファイル名の前後に余分な空白があるかどうかを確認します。
- `rippled.cfg`ファイルを編集し、`[validators_file]`設定を削除します。バリデータ設定を`rippled.cfg`ファイルに直接追加します。例:
[validator_list_sites]
https://vl.ripple.com
[validator_list_keys]
ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
## データベースパスを作成できない
@@ -111,8 +110,8 @@ Aborted (core dumped)
```text
2018-Aug-21 23:06:38.675117810 SHAMapStore:ERR state db error:
writableDbExists false archiveDbExists false
writableDb '/var/lib/rippled/db/rocksdb/rippledb.11a9' archiveDb '/var/lib/rippled/db/rocksdb/rippledb.2d73'
writableDbExists false archiveDbExists false
writableDb '/var/lib/rippled/db/rocksdb/rippledb.11a9' archiveDb '/var/lib/rippled/db/rocksdb/rippledb.2d73'
To resume operation, make backups of and remove the files matching /var/lib/rippled/db/state* and contents of the directory /var/lib/rippled/db/rocksdb
@@ -149,7 +148,7 @@ path=/var/lib/rippled/custom_nudb_path
以下のようなエラーメッセージが出力される場合、`rippled.cfg`ファイルの`[ledger_history]``online_delete`に矛盾する値が指定されています。
```テキスト
```text
Terminating thread rippled: main: unhandled St13runtime_error 'online_delete must not be less than ledger_history (currently 3000)
```
@@ -162,7 +161,7 @@ Terminating thread rippled: main: unhandled St13runtime_error 'online_delete mus
以下のようなエラーが出力される場合は、`rippled.cfg`ファイルの`node_size`設定の値が誤っています。
```テキスト
```text
Terminating thread rippled: main: unhandled N5beast14BadLexicalCastE 'std::bad_cast'
```
@@ -173,23 +172,43 @@ Terminating thread rippled: main: unhandled N5beast14BadLexicalCastE 'std::bad_c
以下のようなエラーが出力される場合は、`rippled.cfg`の[履歴シャーディング](history-sharding.html)の設定が不完全です。
```テキスト
```text
Terminating thread rippled: main: unhandled St13runtime_error 'shard path missing'
```
設定に`[shard_db]`スタンザが含まれている場合、このスタンザには`path`フィールドが指定されている必要があります。このフィールドは、`rippled`がシャードストアーのデータを書き込むことができるディレクトリを指しています。このエラーが発生する場合は、`path`フィールドが欠落しているか、誤った位置に指定されています。構成ファイルで余分な空白やスペルミスがないかどうかを確認し、[シャード設定の例](configure-history-sharding.html#2-rippledcfgの編集)と比較してください。
## サポート対象外のシャードストアータイプ: RocksDB
## ShardStoreがRocksDBを開くかまたは作成することができない
RocksDBは、[履歴シャーディング](history-sharding.html)のバックエンドとしてサポートされなくなりました。RocksDBシャードストアーを定義している既存の構成がある場合は、サーバーが起動に失敗します。[新規: rippled 1.3.1][]
[履歴シャーディング](history-sharding.html)を有効にし、その後設定を変更してNuDBではなくRocksDBを使用するように設定した場合、サーバーは既存のNuDBデータをRocksDBデータとして読み取ろうとし、起動に失敗します。この場合、サーバーは以下のようなエラーを書き込みます。
この場合、log startupコマンドの直後にプロセスが終了し、出力ログの早い段階で次のようなメッセージが表示されます。
```テキスト
ShardStore:ERR shard 504 error: Unable to open/create RocksDB: Invalid argument: /var/lib/rippled/db/shards/504: does not exist (create_if_missing is false)
```text
ShardStore:ERR Unsupported shard store type: RocksDB
```
この問題を修正するには、以下のいずれかを行います。
- 設定されているフォルダーから既存のシャードデータを移動する
- ディスク上のシャードストアーの位置を変更するため、`rippled.cfg`ファイルの`[shard_db]`スタンザの`path`を変更する。
- NuDBを使用するようにシャードストアーを変更す
この問題を修正するには、以下のいずれかを行ってからサーバーを再起動します
- 代わりにNuDBを使用するようにシャードストアーを変更します。
- 履歴シャーディングを無効にします。
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](the-rippled-server.html)
- [技術に関するよくある質問](technical-faq.html)
- **チュートリアル:**
- [ログメッセージについて](understanding-log-messages.html)
- [容量の計画](capacity-planning.html)
- **リファレンス:**
- [rippled APIリファレンス](rippled-api.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

View File

@@ -1,6 +1,6 @@
# ログメッセージについて
以下のセクションでは、`rippled`サーバーのデバッグログに出力される最も一般的なログメッセージタイプとその解釈を説明します。
以下のセクションでは、[`rippled`サーバー](the-rippled-server.html)のデバッグログに出力される最も一般的なログメッセージタイプとその解釈を説明します。
これは、`rippled`の[問題を診断する](diagnosing-problems.html)上で重要なステップです。
@@ -27,11 +27,26 @@ Terminating thread rippled: main: unhandled St13runtime_error
上記のいずれにも該当しない場合は、その問題をセキュリティ上重要なバグとしてRippleに報告してください。Rippleでクラッシュを再現できる場合は、報奨を受領できる可能性があります。詳細は<https://ripple.com/bug-bounty/>を参照してください。
## Already validated sequence at or past
以下のようなログメッセージが出力される場合は、サーバーが異なるレジャーインデックスの検証を順不同で受信しています。
```text
2018-Aug-28 22:55:58.316094260 Validations:WRN Val for 2137ACEFC0D137EFA1D84C2524A39032802E4B74F93C130A289CD87C9C565011 trusted/full from nHUeUNSn3zce2xQZWNghQvd9WRH6FWEnCBKYVJu2vAizMxnXegfJ signing key n9KcRZYHLU9rhGVwB9e4wEMYsxXvUfgFxtmX25pc1QPNgweqzQf5 already validated sequence at or past 12133663 src=1
```
この種類のメッセージが時折発生しても通常は問題ありません。この種類のメッセージが同じ送信バリデータで頻繁に発生する場合は、以下のような問題がある可能性があります(可能性の高いものから順に示しています)。
- メッセージを書き込むサーバーにネットワークの問題がある。
- メッセージに表示されているバリデータにネットワークの問題がある。
- メッセージに表示されているバリデータが悪意のある振る舞いをしている。
## Connection reset by peer
以下のメッセージは、ピア`rippled`サーバーによって接続が閉じられたことを示します。
```テキスト
```text
2018-Aug-28 22:55:41.738765510 Peer:WRN [012] onReadMessage: Connection reset by peer
```
@@ -43,28 +58,44 @@ Terminating thread rippled: main: unhandled St13runtime_error
- サーバーからの要求でピアに過剰な負担がかかり、ピアがサーバーをドロップした。
## No hash for fetch pack
## InboundLedger 11 timeouts for ledger
以下のようなメッセージは、[履歴シャーディング](history-sharding.html)のために履歴レジャーをダウンロードする際に、`rippled` v1.1.0以前のバグが原因で発生します。
```テキスト
2018-Aug-28 22:56:21.397076850 LedgerMaster:ERR No hash for fetch pack.Missing Index 7159808
```text
InboundLedger:WRN 11 timeouts for ledger 8265938
```
これらは安全に無視できます。
これは、サーバーがそのピアに対して特定のレジャーデータを要求する際に問題が発生していることを示しています。[レジャーインデックス](basic-data-types.html#レジャーインデックス)が、[server_infoメソッド][]により報告される最新の検証済みレジャーのインデックスよりもかなり小さい場合は、サーバーが[履歴シャード](history-sharding.html)のダウンロード中である可能性があります。
これは厳密には問題ではありませんが、レジャー履歴を迅速に取得したい場合は、`[ips_fixed]`構成スタンザを追加または編集してからサーバーを再起動することで、すべての履歴が記録されたピアに接続するように`rippled`を構成できます。たとえば、すべての履歴が記録されたRippleのサーバーに常に接続するには、以下のようにします。
```
[ips_fixed]
s2.ripple.com 51235
```
## InboundLedger Want hash
以下のようなログメッセージは、サーバーが他のサーバーにレジャーデータを要求していることを示しています。
```text
InboundLedger:WRN Want: 5AE53B5E39E6388DBACD0959E5F5A0FCAF0E0DCBA45D9AB15120E8CDD21E019B
```
これは、サーバーの同期中、埋め戻し中、[履歴シャード](history-sharding.html)のダウンロード中は正常です。
## LoadMonitor:WRN Job
以下のようなメッセージは、機能の実行に時間がかかっている場合この例では11秒以上に出力されます。
```テキスト
```text
2018-Aug-28 22:56:36.180827973 LoadMonitor:WRN Job: gotFetchPack run: 11566ms wait: 0ms
```
以下のようなメッセージは、ジョブの実行待機に時間がかかっている場合この例でも11秒以上に出力されます。
```テキスト
```text
2018-Aug-28 22:56:36.180970431 LoadMonitor:WRN Job: processLedgerData run: 0ms wait: 11566ms
2018-Aug-28 22:56:36.181053831 LoadMonitor:WRN Job: AcquisitionDone run: 0ms wait: 11566ms
2018-Aug-28 22:56:36.181110594 LoadMonitor:WRN Job: processLedgerData run: 0ms wait: 11566ms
@@ -89,89 +120,107 @@ type=RocksDB
```
## View of consensus changed during open
## No hash for fetch pack
以下のようなログメッセージが出力される場合は、サーバーがネットワークの他の部分と同期していません
以下のようなメッセージは、[履歴シャーディング](history-sharding.html)のために履歴レジャーをダウンロードする際に、`rippled` v1.1.0以前のバグが原因で発生します
```テキスト
2018-Aug-28 22:56:22.368460130 LedgerConsensus:WRN View of consensus changed during open status=open, mode=proposing
2018-Aug-28 22:56:22.368468202 LedgerConsensus:WRN 96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661 to 00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E
2018-Aug-28 22:56:22.368499966 LedgerConsensus:WRN {"accepted":true,"account_hash":"89A821400087101F1BF2D2B912C6A9F2788CC715590E8FA5710F2D10BF5E3C03","close_flags":0,"close_time":588812130,"close_time_human":"2018-Aug-28 22:55:30.000000000","close_time_resolution":30,"closed":true,"hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_index":"3","parent_close_time":588812070,"parent_hash":"5F5CB224644F080BC8E1CC10E126D62E9D7F9BE1C64AD0565881E99E3F64688A","seqNum":"3","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
```text
2018-Aug-28 22:56:21.397076850 LedgerMaster:ERR No hash for fetch pack. Missing Index 7159808
```
サーバー起動後の最初の515分間に、サーバーがネットワークの他の部分と同期せず、このようなメッセージが出力されることは特に異常な動作ではありません。サーバー起動後かなり経過してからこれらのメッセージが書き込まれる場合は、問題が発生している可能性があります。一般的な原因としては、信頼性の低いネットワーク接続や不十分なハードウェアスペックなどが考えられます。また、同じハードウェアで実行されている他のプロセスがリソースをめぐって`rippled`と競合している場合にも発生する可能性があります。(`rippled`とリソースをめぐって競合する可能性のある他のプロセスの例としては、スケジュール済みバックアップ、ウィルススキャナー、定期的なデータベースクリーナーなどがあります。)
## Already validated sequence at or past
以下のようなログメッセージが出力される場合は、サーバーが異なるレジャーシーケンスの検証を順不同で受信しています。
```テキスト
2018-Aug-28 22:55:58.316094260 Validations:WRN Val for 2137ACEFC0D137EFA1D84C2524A39032802E4B74F93C130A289CD87C9C565011 trusted/full from nHUeUNSn3zce2xQZWNghQvd9WRH6FWEnCBKYVJu2vAizMxnXegfJ signing key n9KcRZYHLU9rhGVwB9e4wEMYsxXvUfgFxtmX25pc1QPNgweqzQf5 already validated sequence at or past 12133663 src=1
```
この種類のメッセージが時折発生しても通常は問題ありません。この種類のメッセージが同じ送信バリデータで頻繁に発生する場合は、以下のような問題がある可能性があります(可能性の高いものから順に示しています)。
- メッセージを書き込むサーバーにネットワークの問題がある。
- メッセージに表示されているバリデータにネットワークの問題がある。
- メッセージに表示されているバリデータが悪意のある振る舞いをしている。
## Unable to determine hash of ancestor
以下のようなログメッセージは、サーバーがピアからの検証メッセージを認識するけれども、サーバーが基盤としている親レジャーバージョンを認識しない場合に発生します。これは、サーバーがネットワークと同期している場合には正常です。
```テキスト
2018-Aug-28 22:56:22.256065549 Validations:WRN Unable to determine hash of ancestor seq=3 from ledger hash=00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E seq=12133675
```
サーバー起動後の515分以外の時点でこのメッセージが頻繁に発生する場合は、問題が発生している可能性があります。
## InboundLedger Want hash
以下のようなログメッセージは、サーバーが他のサーバーにレジャーデータを要求していることを示しています。
```テキスト
InboundLedger:WRN Want: 5AE53B5E39E6388DBACD0959E5F5A0FCAF0E0DCBA45D9AB15120E8CDD21E019B
```
これは、サーバーの同期中、埋め戻し中、[履歴シャード](history-sharding.html)のダウンロード中は正常です。
## InboundLedger 11 timeouts for ledger
```テキスト
InboundLedger:WRN 11 timeouts for ledger 8265938
```
これは、サーバーがそのピアに対して特定のレジャーデータを要求する際に問題が発生していることを示しています。[レジャーインデックス](basic-data-types.html#レジャーインデックス)が、[server_infoメソッド][]により報告される最新の検証済みレジャーのインデックスよりもかなり小さい場合は、サーバーが[履歴シャード](history-sharding.html)のダウンロード中である可能性があります。
これは厳密には問題ではありませんが、レジャー履歴を迅速に取得したい場合は、`[ips_fixed]`構成スタンザを追加または編集してからサーバーを再起動することで、すべての履歴が記録されたピアに接続するように`rippled`を構成できます。たとえば、すべての履歴が記録されたRippleのサーバーに常に接続するには、以下のようにします。
```
[ips_fixed]
s2.ripple.com 51235
```
これらは安全に無視できます。
## Potential Censorship
XRP Ledgerが取引検閲の可能性を検出すると、以下のようなログメッセージが出力されます。ログメッセージと取引検閲検出機能の詳細については、[取引検閲の検知](transaction-censorship-detection.html)を参照してください。
XRP Ledgerが取引検閲の可能性を検出すると、以下のようなログメッセージが出力されます。ログメッセージと取引検閲検出機能の詳細は、[取引検閲の検知](transaction-censorship-detection.html)を参照してください。
**警告メッセージ**
```テキスト
```text
LedgerConsensus:WRN Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851545.
```
**エラーメッセージ**
```テキスト
LedgerConsensus:ERR Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851605.Additional warnings suppressed.
```text
LedgerConsensus:ERR Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851605. Additional warnings suppressed.
```
## シャード: No such file or directory
`rippled` 1.3.1のバグが原因で、[履歴シャーディング](history-sharding.html)を有効にしたときに次のようなログメッセージが書き込まれることがあります。
```text
ShardStore:ERR shard 1804: No such file or directory
ShardStore:ERR shard 354: No such file or directory
ShardStore:ERR shard 408: No such file or directory
ShardStore:ERR shard 2927: No such file or directory
ShardStore:ERR shard 2731: No such file or directory
ShardStore:ERR shard 2236: No such file or directory
```
これは、サーバーが新しい履歴シャードの取得を開始しようとしたものの、シャードを格納するための新しいディレクトリーを作成できなかったことを示します。このバグにより、rippled 1.3.1は新しいシャードを取得できません。[修正は近日リリース予定](https://github.com/ripple/rippled/pull/3014)です。
このエラーは、上記のバグのほかに、`rippled`が**起動後**に基となるファイルシステムに書き込めなくなった場合にも起こります。考えられる原因は次のとおりです。
- ストレージメディアのハードウェア障害
- ファイルシステムがアンマウントされた
- シャードフォルダーが削除された
**ヒント:** 一般的に、サービスが停止している場合は、`rippled`のデータベースファイルを削除しても安全ですが、サーバーの稼働中には決してデータベースファイルを削除しないでください。
## Unable to determine hash of ancestor
以下のようなログメッセージは、サーバーがピアからの検証メッセージを認識するけれども、サーバーが基盤としている親レジャーバージョンを認識しない場合に発生します。これは、サーバーがネットワークの他の部分と同期していない場合に発生することがあります。
```text
2018-Aug-28 22:56:22.256065549 Validations:WRN Unable to determine hash of ancestor seq=3 from ledger hash=00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E seq=12133675
```
{% include '_snippets/unsynced_warning_logs.md' %}
<!--_ -->
## View of consensus changed during open
以下のようなログメッセージが出力される場合は、サーバーがネットワークの他の部分と同期していません。
```text
2018-Aug-28 22:56:22.368460130 LedgerConsensus:WRN View of consensus changed during open status=open, mode=proposing
2018-Aug-28 22:56:22.368468202 LedgerConsensus:WRN 96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661 to 00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E
2018-Aug-28 22:56:22.368499966 LedgerConsensus:WRN {"accepted":true,"account_hash":"89A821400087101F1BF2D2B912C6A9F2788CC715590E8FA5710F2D10BF5E3C03","close_flags":0,"close_time":588812130,"close_time_human":"2018-Aug-28 22:55:30.000000000","close_time_resolution":30,"closed":true,"hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_index":"3","parent_close_time":588812070,"parent_hash":"5F5CB224644F080BC8E1CC10E126D62E9D7F9BE1C64AD0565881E99E3F64688A","seqNum":"3","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
```
{% include '_snippets/unsynced_warning_logs.md' %}
<!--_ -->
## We are not running on the consensus ledger
```text
NetworkOPs:WRN We are not running on the consensus ledger
```
{% include '_snippets/unsynced_warning_logs.md' %}
<!--_ -->
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](the-rippled-server.html)
- [技術に関するよくある質問](technical-faq.html)
- **チュートリアル:**
- [問題の診断](diagnosing-problems.html)
- [容量の計画](capacity-planning.html)
- **リファレンス:**
- [rippled APIリファレンス](rippled-api.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}