bitcoin.sourceforge.net が落ちている
ご存じでなければ、ビットコインの公式サイトが落ちている。
http://bitcoin.sourceforge.net/
You are running bitweaver in TEST mode
* Click here to log a bug, if this appears to be an error with theapplication. * Go here to begin the installation process, if you haven’t done so already. * To hide this message, please set the IS_LIVE constant to TRUE in your kernel/config_inc.php file.
ダウンロードしたら起動しました。CPU をかなり使っているので、ちゃんと動いているはずです。 既存ブロックがダウンロードされていませんが、 これはバグでしょうか、 それとも新機能でしょうか ?
Gnome のシステムトレイはあまり安定していません。 アイコンが消えてしまって、 プログラムに戻る術がなくなることがあります。 これがビットコインでも起こり得ることを確認しました。 既にビットコインが起動している状態でビットコインを起動すると、 既に動いているビットコイン処理の GUI が前面に出るようになっていると嬉しいです。
そういう意味です。プログラムを動かしている間、 ステータスバーに表示されるブロック数は全く増えませんでした。 debug.log を添付しています。
Gnome でトレイアイコンを検査するには、 通知領域を一度削除してから戻すとよいです。 通知領域を戻した後にアイコンが表示されていれば、 正しく動いているということになります。
普段、 私はアプリケーションの設定でトレイ最小化はオフ、 トレイ終了をオンにしています。 そしてアプリケーションは常時最小化しています。 こうすれば、 誤ってプログラムを閉じる事故もなく、 トレイから開ける利便性も保てます ( タスクバーにはウインドウを表示しませんが、 クリックするとサブメニューで開いているウインドウ一覧を出すアイコンを置いています )。 もしトレイアイコンが消えたら、 設定でアイコン表示をいったん無効にしてから再度有効にすれば戻ります。 ところが、 ビットコインの設定ではこれができません。 トレイ最小化のチェックを入れないと、 トレイ終了のチェックが入れられないからです。
ようやくブロックが増え始めました。Windows 版より明らかに増え始めるまでに時間がかかりますし、 増え方も Windows 版より遅いように思えます。 送ってもらった Linux ビルドにデバッグが有効になっていたりしないでしょうか ? ブロックは 1 秒あたり約 15 個ずつ増えています ( 時計を見ながらの目視推定 )。 Windows 版での増加速度は計っていませんでしたが、 もっと速かった気がします。
増加が速くなり始めるまでに 30 分くらいかかりました。 興味深いことに、 安定して増加し始める前に CPU 使用率が上がり、 安定して増加し始めると下がりました。 とはいえ今回はブロックが最初の数分で 2 まで増えました。 まだビットコインは生成できていません。 我慢が続く限りビットコイン生成を待つつもりですが、 我慢が切れるまでに 1 枚も生成できなかったら、 Wine 版に戻ります。
現在の debug.log を添付しています。
ビットコインを起動した時、 ビットコインのポートが使えないと、 コマンドラインに以下のメッセージが出ます。 ポートが使えるときは、 このメッセージは出ません。 既定ポートが塞がっているときは、 ビットコインが別のポートを選べるようにはできないでしょうか ? BitTorrent クライアントでも同じことがあります。 再起動すると、 直前まで開いていたポートが閉じています。 ポートを変更するだけで動くようになります。
/usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64 Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so /usr/lib/gio/modules/libgioremote-volume-monitor.so: wrong ELF class: ELFCLASS64 Failed to load module: /usr/lib/gio/modules/libgioremote-volume-monitor.so /usr/lib/gio/modules/libgiogconf.so: wrong ELF class: ELFCLASS64 Failed to load module: /usr/lib/gio/modules/libgiogconf.so
ビットコインを同時に二つ動かす理由は、 ビットコインを別のインスタンスに移すためです。 もちろん、 別々のデータディレクトリを使う必要があります。 これはコマンドライン引数で指定できるとよいかもしれません。 いまは仮想マシンにビットコインのデータフォルダを移して対応しています。 ビットコインを終了して別のデータディレクトリで起動し直すのは、 未確定のビットコインがある状態で終了するとそれを失う恐れがあるので、 よい解ではありません。
ポート使用中エラーが出たとき、 ビットコインは確実に動いていませんでした。 私の経験ではビットコインは素早く確実に終了しますが、 ポートが再び使えるようになるまで 30 秒から 3 分 ( 記憶からの推定 ) かかります。 Wine 上の bitcoin 0.1.5 から Linux ビルドに切り替えた時、 また Linux ビルドから Wine 上の bitcoin 0.1.5 に切り替えた時に発生しました。
もう一つ気付いた点として、 about ダイアログのテキストが収まりきっておらず、 ダイアログのサイズも変更できません。
多重起動したい別の場面は、 ビットコインのアップグレード時です。 旧版のビットコインでは生成チェックボックスを外し、 別データディレクトリで新版のビットコインを起動して採掘を開始します。 旧アプリのコインが熟成したら新アプリに送って、 それから旧アプリを閉じます。 既存データを引き継いだ上書きアップグレードよりも、 クリーンインストールの方を好みます。
この Linux ビルドに貢献した皆さん、 本当によい仕事をしてくれました ! 苦労に感謝します。ビットコインが熟成し始めたので、 Wine 上の Windows 版と比較してコイン生成性能が同等以上か劣るか判断がつくまで、 当面 Linux クライアントを使い続けます。
Linux ビルドはこの 20 時間でビットコインを十分な量生成できていますし、 データベースエラーについてのあなたの説明も信じていますので、 今後は Linux ビルドを使い続けるつもりです。 Linux ビルドで少し困った点が一つあって、 ファンが 50% から 100% に上がってしまいました。:-P CPU 制限はかけられると分かっていますので、 耐えられなくなって生成量の減少を許容できるなら、 そのうち CPU 制限をかけるかもしれません。 あるいは、 もっと音楽を聴くことにすべきかもしれません…
熟成中のコインを 6 セットも失いました ! 熟成中のビットコインが 10 セットありました。 最後のセットは 0:22 頃に生成されたものです。 ビットコインが固まる前に 2/未確認まで進んでいました。 10:10 の時点で、 0:22 に生成されたビットコインはまだ 2/未確認のままでした。 あなたがコインを失うことはないと言ってくれていたので、 ビットコインを終了して再起動しました。 よかった点として、 終了も起動も非常に滑らかでした。 しかし残念なことに、 ブロックが更新された時に、 6 セット分のビットコインを失いました。 4 セットはまだ未確認でしたが、 2 セットは確認済みでした。 そして、 そのどれもが跡形もなく消えています。「Show Generated Coins」 オプションが利用可能になった今、 失敗したビットコイン生成も戻してくれるとよいかもしれません。 あのビットコインたちが空気の中に消えていったというのが、 とにかく気に入りません。 今のところまだ Linux ビルドを動かしていますが、 直近 24 時間に生成した 10 セットのうち 6 セットが消えた今、 Wine 版が急に魅力的に見え始めています。 debug.log を添付しています。
私のネットワーク接続はコンピューター直結です。 ISP はインターネット接続に VPN を要求してきます。 そして 2 枚目の NIC を持っていて、 そこからインターネットを他の機器に共有しています。 自分のコンピューター利用時の IP アドレスは実 IP ですが、 2 枚目の NIC 経由で接続する機器は NAT を使います。 仮想マシン経由で接続する時も NAT です。 設定の手間はほぼかかっていません。 Ubuntu の NetworkManager に 2 枚目の NIC 経由でインターネット接続を共有するオプションがあり、 VirtualBox にも NAT を使うオプションがあります。
ビットコインを 2 セット分また失ってしまいましたので、 その問題はまだ直っていません。 状況が理解できるようになった今、 少しは耐えられます。 当面はビットコインのセットが熟成し始めるたびにビットコインを再起動する運用にします。 Linux と Wine の間を行ったり来たりするかもしれませんが、 新版が出るたびに必ず検査します。 今この瞬間も Linux ビルドを動かしています。
君からの添付ファイルは問題なく届いている。 大きな添付をマルッティに送らない方が良いと思っただけだ。
このバグは再現できない。 貼り付け、 ブロック完了、 その組み合わせ、 あるいは他の何かが原因なのか、 分からない。
…
ただ、 ダウンロードが始まった後、 自分の BitTorrent クライアントを見たら、 忘れていたトレントがあって、 上り帯域が私の設定した上限近くまで使われていた。
データディレクトリを SSD カードに戻して、 bitcoin test 6 を起動した。 今日、 ログに Db::open が出るかたちでセグメンテーション違反が発生した。 720p mkv 動画を見ている間、 設定をプロセッサー / コア 1 つだけ使うように変えていた。 セグメンテーション違反には、 映画が終わってから気付いた。
test7 を、 新しいデータディレクトリで開始しました。 ブロックのダウンロードが格段に速く始まりました。 これまでの Linux ビルドでは数分かかっていましたが、 今回は約 15 秒で済みました。 ブロックをダウンロードしている間に 1 回クラッシュし、 ターミナルに以下のメッセージが出ました。
../include/wx/thrimpl.cpp(50): assert “m_internal” failed in TryLock(): wxMutex::TryLock(): not initialized [in child thread] Trace/breakpoint trap
ログファイルを添付しますが、 ビットコイン再起動の前にバックアップを取り忘れたので、 ログのどの時点でクラッシュが起きたかは分かりません。
幸いセグメンテーション違反にはまだ遭遇していません。 直前までのビルドでセグメンテーション違反の頻度には大きなばらつきがありましたので、 引き続き動かして、 問題があれば知らせます。