1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1VRymg-0008Ta-ML
for bitcoin-development@lists.sourceforge.net;
Fri, 04 Oct 2013 06:22:42 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.181 as permitted sender)
client-ip=209.85.215.181; envelope-from=gavinandresen@gmail.com;
helo=mail-ea0-f181.google.com;
Received: from mail-ea0-f181.google.com ([209.85.215.181])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VRymf-00082i-J8
for bitcoin-development@lists.sourceforge.net;
Fri, 04 Oct 2013 06:22:42 +0000
Received: by mail-ea0-f181.google.com with SMTP id d10so1588384eaj.12
for <bitcoin-development@lists.sourceforge.net>;
Thu, 03 Oct 2013 23:22:35 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.15.108.202 with SMTP id cd50mr505957eeb.68.1380867755243;
Thu, 03 Oct 2013 23:22:35 -0700 (PDT)
Received: by 10.223.201.132 with HTTP; Thu, 3 Oct 2013 23:22:34 -0700 (PDT)
In-Reply-To: <CAJna-Hj1c0k3Gb7rEMBeU9nQsFophU2CYzGUOEo3JxieOYA5dA@mail.gmail.com>
References: <CAJna-Hi+eyRnZUtHpfvod_uRCmjPOL5HS3ZZpr54yzbKRRT9-w@mail.gmail.com>
<CAJHLa0MHSjZ_mwsCKa=rd1_39H0yq9j2jVwr0qWFTxTtrWXPCQ@mail.gmail.com>
<CAJna-Hj1c0k3Gb7rEMBeU9nQsFophU2CYzGUOEo3JxieOYA5dA@mail.gmail.com>
Date: Fri, 4 Oct 2013 16:22:34 +1000
Message-ID: <CABsx9T2OvOs9ijj8kk4ZdBT5u-2Bb3rYG0AZtk3FFDWi+H_oHw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: slush <slush@centrum.cz>
Content-Type: multipart/alternative; boundary=089e01681ba408a8d604e7e45449
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gavinandresen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: centrum.cz]
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1VRymf-00082i-J8
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] bitcoind stops responding
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 04 Oct 2013 06:22:42 -0000
--089e01681ba408a8d604e7e45449
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Oct 1, 2013 at 6:58 PM, slush <slush@centrum.cz> wrote:
> One process is asking getinfo every second as a fallback to possibly
> misconfigured blocknotify. It also calls getblocktemplate every 30 second.
>
getinfo does a bunch of stuff; with 0.9 you will be able to use
getbestblockhash instead.
> Second process is calling getinfo once a minute to check if bitcoind is
> working. If it don't receive a response in a minute, it kills bitcoind and
> starts it again.
>
If you just want to see if bitcoind is responding to RPC requests, then
'help getinfo' would do the trick without acquiring any locks.
RE: running into the maximum-of-4-keepalive-requests : simple workaround is
to run with -rpcthreads=11 (or however many keepalive connections you need
to support). I agree that the rpc code should be smarter; making the last
rpc thread ignore keepalive and always disconnecting should be a fairly
simple patch, and "patches welcome."
--
--
Gavin Andresen
--089e01681ba408a8d604e7e45449
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
On Tue, Oct 1, 2013 at 6:58 PM, slush <span dir=3D"ltr"><<a href=3D"mail=
to:slush@centrum.cz" target=3D"_blank">slush@centrum.cz</a>></span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">One process is asking getinfo every second as a fallback t=
o possibly misconfigured blocknotify. It also calls getblocktemplate every =
30 second.<br></div></blockquote><div><br></div><div>getinfo does a bunch o=
f stuff; with 0.9 you will be able to use getbestblockhash instead.</div>
<div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">
<div class=3D"gmail_extra">Second process is calling getinfo once a minute =
to check if bitcoind is working. If it don't receive a response in a mi=
nute, it kills bitcoind and starts it again.</div></div></blockquote><div>
<br></div><div>If you just want to see if bitcoind is responding to RPC req=
uests, then 'help getinfo' would do the trick without acquiring any=
locks.</div><div><br></div><div>RE: running into the maximum-of-4-keepaliv=
e-requests : simple workaround is to run with -rpcthreads=3D11 (or however =
many keepalive connections you need to support). =A0I agree that the rpc co=
de should be smarter; making the last rpc thread ignore keepalive and alway=
s disconnecting should be a fairly simple patch, and "patches welcome.=
"</div>
<div><br></div></div>-- <br>--<br>Gavin Andresen<br>
</div></div>
--089e01681ba408a8d604e7e45449--
|
