blkmond lite

[metonymous]

hey all, I couldn't grok blkmond, or seemingly get it working. it runs and sits there... doing nothing even when a block turns up. Anyway;

from that engineering "do it yourself" mentality I wrote a substitute that operates in possibly the least efficient way possible, it just polls bitcoind over RPC ever 0.1 of a second. Huzzah! Anyway it works, and it's a "fixed cost" work, it won't increase usage if you increase pool size.

I jokingly called it pollpokepush.py (it's even fun to say!),

To get it working:

• download https://github.com/jgarzik/python-bitcoinrpc into the directory containing the script
• change RPCUSER and RPCPASSWORD

Code:

#!/usr/bin/env python
from jsonrpc.authproxy import AuthServiceProxy
import sys
import os

access = AuthServiceProxy("http://RPCUSER:RPCPASS@127.0.0.1:8332")
blockcount = access.getblockcount()
from time import sleep
while(True):
        newcount = access.getblockcount()
        if newcount > blockcount:
                os.system("killall -s SIGUSR1 pushpoold")
                sys.stdout.write("B")
                sys.stdout.flush()
                blockcount = newcount
                sleep(1)
        else:
                sleep(0.1)

[1714002893]

1714002893

[1714002893]

1714002893

[1714002893]

1714002893

[1714002893]

1714002893

[xmasterpx]

Yep i had the same problem.
Running Running Running and its doing nothing.

Your little skript works very well. thanks

[lemosax]

This works beautifully.  I could not get blkmond working at all, but your script does the trick, and the clients clearly show the "long poll: new block"

Thanks!

[phorensic]

After two weeks of working flawlessly, blkmond decided it didn't want to send SIGUSR1 anymore.  It was monitoring fine, but not sending the signal.  I just implemented your script on our pool, and it works like magic!  Thanks.

[JoelKatz]

You can use my native long polling patch for bitcoind. It's this simple:

diff -up orig/main.cpp new/main.cpp
--- orig/main.cpp       2011-07-03 17:36:31.538080064 -0700
+++ new/main.cpp        2011-07-03 19:31:18.396649894 -0700
@@ -1586,6 +1586,20 @@ bool CBlock::SetBestChain(CTxDB& txdb, C
     // Update best block in wallet (so we can detect restored wallets)
     if (!IsInitialBlockDownload())
     {
+        // Support long polling
+        string lp_pid=mapArgs["-pollpidfile"];
+        if(lp_pid != "")
+        {
+            FILE *pidFile = fopen(lp_pid.c_str(), "r");
+            if(pidFile!=NULL)
+            {
+                int pid=0;
+                if ((fscanf(pidFile, "%d", &pid) == 1) && (pid>1))
+                    kill((pid_t) pid, SIGUSR1);
+                fclose(pidFile);
+            }
+        }
+    
         CWalletDB walletdb;
         const CBlockLocator locator(pindexNew);

Then just start bitcoind with '-pollpidfile=/var/run/pushpoold.pid' (or whatever the path to your pid file is from your config). Do not use this patch and use anything else to send a SIGUSR1 to pushpoold! (Bitcoind and pushpoold must run as the same user or this won't work.)

[phorensic]

JoelKatz, I love the work you have done on bitcoind and I will be using your patches soon.  I would like to see your fork (maintained by the other guy on Github) become a bit more stable on the larger pools and I will start running it.

[JoelKatz]

JoelKatz, I love the work you have done on bitcoind and I will be using your patches soon.  I would like to see your fork (maintained by the other guy on Github) become a bit more stable on the larger pools and I will start running it.

Thanks. He's done a good job of porting it to 0.3.24 and maintaining it. I'm glad someone did that, as I haven't had the time lately. I may be having a lot more free time in the next week or so, so I hope get back to it aggressively.

[froggy]

Excellent stuff, JoelKatz.  Can I just check...

Then just start bitcoind with '-pollpidfile=/var/run/pushpoold.pid'.

I take it that if I have in pushpool's server.json  file...

Code:

   "pid" : "/tmp/pushpoold.pid",

Then I should be using

Code:

 bitcoind -pollpidfile=/tmp/pushpool.pid'. 

Would you be kind enough to confirm this?

Many huge thanks!

[JoelKatz]

Would you be kind enough to confirm this?

Yes.

[Furyan]

JoelKatz, I love the work you have done on bitcoind and I will be using your patches soon.  I would like to see your fork (maintained by the other guy on Github) become a bit more stable on the larger pools and I will start running it.

Thanks. He's done a good job of porting it to 0.3.24 and maintaining it. I'm glad someone did that, as I haven't had the time lately. I may be having a lot more free time in the next week or so, so I hope get back to it aggressively.

Are you referring to Jine's fork of pushpool where you've implemented the long polling and keep-alives in pp?

I love that work too... I just got the stock codebases of bitcoind and pushpool compiled and working but I think I'm going to use your patches instead... much more elegant.

[JoelKatz]

I recently rebased to 0.3.24 and included a few other micro-optimizations.
http://davids.webmaster.com/~davids/bitcoin-4diff.txt

[Furyan]

I recently rebased to 0.3.24 and included a few other micro-optimizations.
http://davids.webmaster.com/~davids/bitcoin-4diff.txt

Blargh. My copy is bleeding-edge git.  Why you have to make it hard?  

[TeraPool]

I recently rebased to 0.3.24 and included a few other micro-optimizations.
http://davids.webmaster.com/~davids/bitcoin-4diff.txt

Blargh. My copy is bleeding-edge git.  Why you have to make it hard?  

Isn't that kind of risky for a production server anyways?

[JoelKatz]

Isn't that kind of risky for a production server anyways?

Yeah, but without people who take that risk, we could never have confidence in the code we are releasing. It's thanks to the folks who first ran my code on live servers that the code is reasonably stable today. So thank him for taking that risk so that you don't have to. (Assuming he's watching it closely. Otherwise, he's just being stupid.)

[Furyan]

Isn't that kind of risky for a production server anyways?

Yeah, but without people who take that risk, we could never have confidence in the code we are releasing. It's thanks to the folks who first ran my code on live servers that the code is reasonably stable today. So thank him for taking that risk so that you don't have to. (Assuming he's watching it closely. Otherwise, he's just being stupid.)

For the moment, the only one taking the risk is me and a couple of others.  And yes, I am watching it closely.

I don't have the production/test server division fully built out yet but when I do, this ceases to be an issue. Crash test dummies can have at it if they wish.