コマンドラインとJSON-RPC

19 件のメッセージ BitcoinTalk サトシ・ナカモト, Theymos, マルッティ・マルミ, The Madhatter, Cdecker 2010年2月23日 — 2010年3月5日

SVN上のバージョン0.2.6はデーモンとして実行でき、コマンドラインまたはJSON-RPCで制御できるようになった。

Linuxではlibgtk2.0-0がインストールされている必要があるが、GUIが実行されている必要はない。うまくいけば、ウィンドウシステムがインストールされていなくてもGTKをインストールできるだろう。

デーモンとして起動するコマンド: bitcoin -daemon [スイッチ…]

または、通常通りUIを実行しつつコマンドラインやJSON-RPCからも制御可能にするには、「-server」スイッチを使用する。 bitcoin -server [スイッチ…]

どちらのスイッチでも、127.0.0.1:8332でローカルソケット接続を受け付けるHTTP JSON-RPCサーバーが実行される。ポートはループバックにバインドされ、ローカルマシンからのみアクセスできるが、実行中のユーザーだけでなくどのアカウントからでもアクセスできる。

コマンドラインから制御するには、インターフェースはスイッチなしのコマンド名の後にパラメータ(ある場合)を続ける。 bitcoin <コマンド> [パラメータ…]

例: bitcoin getinfo
bitcoin getdifficulty
bitcoin setgenerate true
bitcoin stop

これはシンプルなJSON-RPCクライアントで、JSONの結果を表示する。コマンドのリストはrpc.cppを参照してほしい。

Webアプリや自動化されたものは通常、コマンドラインではなくJSON-RPCを直接使用する。すべての主要言語にJSON-RPCライブラリがある。PHPやPythonのようなスクリプト言語では、構文はローカル関数を呼び出すのと同じくらい自然だ。

Quote from: satoshi on February 23, 2010, 10:15:41 PM

SVN上のバージョン0.2.6はデーモンとして実行でき、コマンドラインまたはJSON-RPCで制御できるようになった。

Linuxではlibgtk2.0-0がインストールされている必要があるが、GUIが実行されている必要はない。うまくいけば、ウィンドウシステムがインストールされていなくてもGTKをインストールできるだろう。

デーモンとして起動するコマンド: bitcoin -daemon [スイッチ…]

または、通常通りUIを実行しつつコマンドラインやJSON-RPCからも制御可能にするには、「-server」スイッチを使用する。 bitcoin -server [スイッチ…]

どちらのスイッチでも、127.0.0.1:8332でローカルソケット接続を受け付けるHTTP JSON-RPCサーバーが実行される。ポートはループバックにバインドされ、ローカルマシンからのみアクセスできるが、実行中のユーザーだけでなくどのアカウントからでもアクセスできる。

コマンドラインから制御するには、インターフェースはスイッチなしのコマンド名の後にパラメータ(ある場合)を続ける。 bitcoin <コマンド> [パラメータ…]

例: bitcoin getinfo
bitcoin getdifficulty
bitcoin setgenerate true
bitcoin stop

これはシンプルなJSON-RPCクライアントで、JSONの結果を表示する。コマンドのリストはrpc.cppを参照してほしい。

Webアプリや自動化されたものは通常、コマンドラインではなくJSON-RPCを直接使用する。すべての主要言語にJSON-RPCライブラリがある。PHPやPythonのようなスクリプト言語では、構文はローカル関数を呼び出すのと同じくらい自然だ。

この要件はいずれ撤廃されるのか? GTKを扱うのは面倒だ。

GtkはGUIに必要なので、同じバイナリを使いたい場合はリンクしなければなりません。別のバイナリを作る方法もありますが、どの程度のコード修正やifdefが必要かは分かりません。

  • madhatter2が鋭いヘックスエディタを取り出す

Quote from: theymos on February 24, 2010, 03:07:37 AM

Quote from: satoshi on February 23, 2010, 10:15:41 PM

Linuxではlibgtk2.0-0のインストールが必要だ。

この要件はいずれ撤廃されるのか? GTKを扱うのは面倒だ。 Quote from: satoshi on February 23, 2010, 10:15:41 PM SVN上のバージョン0.2.6はデーモンとして実行でき、コマンドラインまたはJSON-RPCで制御できるようになった。

Linuxではlibgtk2.0-0がインストールされている必要があるが、GUIが実行されている必要はない。うまくいけば、ウィンドウシステムがインストールされていなくてもGTKをインストールできるだろう。

デーモンとして起動するコマンド: bitcoin -daemon [スイッチ…]

または、通常通りUIを実行しつつコマンドラインやJSON-RPCからも制御可能にするには、「-server」スイッチを使用する。 bitcoin -server [スイッチ…]

どちらのスイッチでも、127.0.0.1:8332でローカルソケット接続を受け付けるHTTP JSON-RPCサーバーが実行される。ポートはループバックにバインドされ、ローカルマシンからのみアクセスできるが、実行中のユーザーだけでなくどのアカウントからでもアクセスできる。

コマンドラインから制御するには、インターフェースはスイッチなしのコマンド名の後にパラメータ(ある場合)を続ける。 bitcoin <コマンド> [パラメータ…]

例: bitcoin getinfo
bitcoin getdifficulty
bitcoin setgenerate true
bitcoin stop

これはシンプルなJSON-RPCクライアントで、JSONの結果を表示する。コマンドのリストはrpc.cppを参照してほしい。

Webアプリや自動化されたものは通常、コマンドラインではなくJSON-RPCを直接使用する。すべての主要言語にJSON-RPCライブラリがある。PHPやPythonのようなスクリプト言語では、構文はローカル関数を呼び出すのと同じくらい自然だ。

この要件はいつか解消されますか?GTKを扱いたくないのですが。 GTKを「扱う」のに実際どれくらいの手間がかかるのだろうか?「sudo apt-get install libgtk2.0-0」をして、いくつかの余分なライブラリが置いてあるだけの問題ではないか?GTKは何もする必要はなく、ただそこにあればBitcoinが起動時にリンクでき、GUIがないためgtk-init-checkの呼び出しが失敗して、それで終わりだ。

GTKのリンクを避けるためだけにwxBaseを使用するために、すべてをifdefで台無しにして、別のコンパイルとバイナリを用意するよりマシだ。

Linux From Scratchを使っているので、GTKのような依存関係だらけのパッケージをインストールするのはかなり面倒だ。BitCoinが使わないのに、なぜ十数個のパッケージと数百メガバイトをシステムに追加しなければならないのか?

なぜインストールするかって? 今のところそうしなければならないからだ。その気持ちは分かる。俺はミニマリストのFreeBSDサーバーを運用しているが、Xライブラリでごちゃごちゃにするのは面倒だ。

しかし、Xワークステーションにインストールするのはまったく問題ない。通常、正しい依存関係がすでに揃っているからだ。Tongue

これはおかしいですね…64ビットLinuxサーバーでBitcoinをデーモンとして起動すると、残りの250MBのRAMと700MBのスワップをすべて食い尽くして、最終的にクラッシュします。32ビットのUbuntuデスクトップでは問題なく動作し、メモリ使用量は15MBに留まります。サーバーでは64ビットビルドのBitcoinを実行しています。ビルドに何か問題があるのかもしれません。

メモリ使用量はいつ、どのくらいの速さで増加したか?すぐに、長時間かけてゆっくりと、それとも何かの後のイベントから始まったか?

Ubuntu 9.10 64ビットで-daemonを実行しており、メモリ使用量は安定している。

サーバーでの違いは64ビット以外に何かあるはずだ。GUIがないことによる何らかの不具合かもしれない。メモリリークのデバッグツールが手がかりを与えてくれるかもしれない。

すぐに増加し始めました。valgrindで調べてみます。

OK、wxBaseのみをリンクしGTKをリンクしないビルドターゲットbitcoindを作成した。SVN上のバージョン0.2.7だ。

ui.cppから初期化とシャットダウンの処理をinit.cppに分離したので、ui.cppは純粋なUIのみになった。ui.hはwxUSE_GUI=0の場合にインラインスタブを提供する。ノードからUIへのインターフェース関数は4つだけだ。bitcoindビルドでは、ui.oやuibase.oはリンクしない。

Quote from: sirius-m on February 25, 2010, 04:32:17 PM

すぐに増加し始めました。valgrindで調べてみます。

何かUIの処理が失敗したか、正しく初期化されなかったために、wxWidgets内で無限にリトライしているような感じがする。初期化失敗を無視して実行を続けるハックは、未知の領域に入ることを意味する。このモードではwxをほとんど使用しないという事実に頼っている。wxGetTranslationやwxMutexなど、いくつかは引き続き使用している。

別のデバッグ方法として、gdbで実行し、すべてが静かになりすべてのスレッドがアイドルになるのを待ち、ブレークして、どのスレッドが忙しく何かをしているか、何をしているかを確認する方法がある。

bitcoindはおそらく問題なく動作すると思うが、問題のデバッグをしてもらえると助かる。

wxBaseだけでコンパイルしようとするとエラーが出る。

Code:g++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I”/opt/tdep/include” -I”/usr/include” -DwxUSE_GUI=0 -o obj/nogui/util.o util.cpp In file included from util.cpp:5: headers.h:22:24: error: wx/clipbrd.h: No such file or directory In file included from headers.h:100, from util.cpp:5: db.h: In member function ‘bool CDB::Exists(const K&)’: db.h:140: error: ‘class Db’ has no member named ‘exists’ make: *** [obj/nogui/util.o] Error 1

clipbrd.hはwxBaseにはインストールされない。wxWidgets-2.9.0/include/wx/clipbrd.hをincludeディレクトリに移動しても、「no such file」の2行が消えるだけだ。

wx/clipbrd.hは使用されていないので、#if wxUSE_GUIの中に移動してほしい。

SVNのheaders.hを更新した。

すまない、wxbaseにリンクしたが、コンピュータにはフルのwxWidgetsがあった。

db.h:140のクラスDbにメンバー「exisits」がないというのは変だ。pdb->get、pdb->put、pdb->delはその前にコンパイルできていた。Berkeley DBのバージョン4.7.25を使っているか?

Db::exists() http://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/CXX/frame_main.html http://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/CXX/dbexists.html

おそらく最近existsが追加されたのかもしれない。それ以前はgetを使用していたのだろう。

Berkeley DB 4.5.20を使っている。

DB-4.7.25を使ったらその問題は解決した。

しかし、今度はこのエラーが出ている:

Code:g++ -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I”/usr/include” -I”/opt/tdep/include” -o bitcoind -L”/usr/lib” -L”/usr/local/lib” -L”/opt/tdep/lib” obj/nogui/util.o obj/nogui/script.o obj/nogui/db.o obj/nogui/net.o obj/nogui/irc.o obj/nogui/main.o obj/nogui/rpc.o obj/nogui/init.o obj/sha.o -l wx_baseu-2.9 -Wl,-Bstatic -l boost_system -l boost_filesystem -l db_cxx -Wl,-Bdynamic -l crypto -l gthread-2.0 obj/nogui/init.o: In function wxArrayString::Item(unsigned int) const': init.cpp:(.text._ZNK13wxArrayString4ItemEj[wxArrayString::Item(unsigned int) const]+0x7): undefined reference to wxTheAssertHandler’ init.cpp:(.text._ZNK13wxArrayString4ItemEj[wxArrayString::Item(unsigned int) const]+0x42): undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)’ collect2: ld returned 1 exit status make: *** [bitcoind] Error 1

wxWidgets 2.9.0を使用しているか?2.9.0以外の使用は推奨しない。

wxヘッダー(arrstr.h)にwxBase外の何かへの参照があるようだ。

BitcoinのmakefileからD__WXDEBUG__を削除すれば、おそらく解決するだろう。

それでも動作せず、とにかく動かしたい場合は、wxWidgetsのinclude/wx/arrstr.h、167行目を編集してwxASSERT_MSGをコメントアウトすることができる。

Cdecker 2010年2月27日 原文 · 個別ページ

ヘッドレスモードは非常に便利だ。ようやく夜間にサーバーで生成を始められる。Cheesy

あのwcharの問題は、俺がOSXビルドで行き詰まっていた部分だ。Cheesy

解決されたのを見てうれしい。引き続きハックしていこう。

Quote from: sirius-m on February 24, 2010, 06:17:35 PM

これはおかしいですね…64ビットLinuxサーバーでBitcoinをデーモンとして起動すると、残りの250MBのRAMと700MBのスワップをすべて食い尽くして、最終的にクラッシュします。32ビットのUbuntuデスクトップでは問題なく動作し、メモリ使用量は15MBに留まります。サーバーでは64ビットビルドのBitcoinを実行しています。ビルドに何か問題があるのかもしれません。

sirius-mがこれをデバッグした。64ビット関連の問題だった。

修正はSVNのutil.cppファイルで利用可能になった。