is the witness thing running under win?

Started by tonyk, January 25, 2016, 04:26:17 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

tonyk

#15
Quote from: cube on January 27, 2016, 01:52:14 PM
  However you can try my compiled binary just to test it out. Remember to remove the blockchain and object folders.

https://github.com/btscube/bitshares-2/releases

Testing right now...

Did you change your repository in the last 2 mo. or so? I specifically checked, during this ordeal (last 2-3 days) to see if you have any compilation of your own and I did not see any.

[edit] ...and the same result...same chain ID as in the pic above...
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

cube

#14
Quote from: tonyk on January 26, 2016, 08:13:16 PM

104.236.144.84:1777,   -> 104.236.144.84:1777 last seen 2016-01-26T18:37:49

This is puppies's seed. It would b e interesting to see what it sent you in the p2p log.

Quote from: tonyk on January 26, 2016, 08:13:16 PM
This one 84.200.17.129 from above is a  seed node. The communication went something like...

active: 84.200.17.129:1779 with 97ea3e6a4056decd6d44868e43cb444d883f875cebedfd00a48159a23a95c0b67f   [outbound]

eer 84.200.17.129:1779 because they didn't respond to my request for sync item ids after ["002b0e5966422ef475e20ef2c96acdaec7d51127","002b21e06bbd170a778f9cbc8891fa73f51764b1...

nnection.cpp:202
2016-01-26T19:00:36 p2p:message read_loop on_connection_closed ] Remote peer 84.200.17.129:1779 closed their connection to us

node.cpp:985
2016-01-26T19:00:36 p2p:message read_loop schedule_peer_for_de ] scheduling peer for deletion: 84.200.17.129:1779 (this will not block)

handshaking: 84.200.17.129:1779 with 000000000000000000000000000000000000000000000000000000000000000000  [unknown]

handshaking: 84.200.17.129:1779 with 97ea3e6a4056decd6d44868e43cb444d883f875cebedfd00a48159a23a95c0b67f  [outbound]
84.200.17.129:1779 last seen 2016-01-26T19:00:50


You may like to find out why seed 84.200.17.129 is not responding to your node. Is it blocked?

What about other seeds' communication? Do you have the info?



Quote from: tonyk on January 26, 2016, 08:13:16 PM
some active communications with some non-seed nodes
from p2p.log2016012T1800000

node.cpp:2522
2016-01-26T18:37:51 p2p:message read_loop fetch_next_batch_of_ ] sync: sending a request for the next items after 002b2d966b7cf344032b787762760e770e22c90d to peer 159.203.101.247:54765, (full request is ["002b0e5966422ef475e2...

node.cpp:2424
2016-01-26T18:37:51 p2p:message read_loop           on_message ] handling message blockchain_item_ids_inventory_message_type 57179945df4926db3b90931eafa6834ba1213ce8 size 40010 from peer 159.203.101.247:5
node.cpp:1754
2016-01-26T18:37:51 p2p:message read_loop on_blockchain_item_i ] sync: received a list of 2000 available items from 159.203.101.247:54765
node.cpp:1754
2016-01-26T18:37:51 p2p:message read_loop on_blockchain_item_i ] sync: received a list of 2000 available items from 159.203.101.247:54765



Since you can retrieve the p2p log, the most recent 20 to 30 lines of debug information (before and just after it got stuck) should give some clues. Post them here.

Quote from: tonyk on January 26, 2016, 08:13:16 PM
PS
and the witness node spit a new line (for the first time) after 2h or so later:
2095358ms ntp        ntp.cpp:177                   read_loop            ] ntp_de
lta_time updated to 950002 us


You can ignore them. They are updating the internal clock.

I doubt the devs tagged the release wrongly and provided an 'old' binary.  However you can try my compiled binary just to test it out. Remember to remove the blockchain and object folders.

https://github.com/btscube/bitshares-2/releases
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

tonyk

Quote from: abit on January 27, 2016, 02:06:07 AM
Quote from: tonyk on January 27, 2016, 01:47:40 AM
Quote from: abit on January 26, 2016, 08:18:00 PM
Quote from: tonyk on January 26, 2016, 08:13:16 PM
@abit same results after the last instruction - rescan blockchain and all
I'm sure you're running with an old version.

Release date 1/04/2016


Those exes of version 0103b are built at least one week after the release. See https://github.com/cryptonomex/graphene/issues/514
@tonyk dates of your files are 1/4, so won't be the newest version.
Try install again.

well if this is the case... you should have simply informed me that if I have not build them myself from source...they are likely old...

anyways... Thanks everyone.
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

abit

Quote from: tonyk on January 27, 2016, 01:47:40 AM
Quote from: abit on January 26, 2016, 08:18:00 PM
Quote from: tonyk on January 26, 2016, 08:13:16 PM
@abit same results after the last instruction - rescan blockchain and all
I'm sure you're running with an old version.

Release date 1/04/2016


Those exes of version 0103b are built at least one week after the release. See https://github.com/cryptonomex/graphene/issues/514
@tonyk dates of your files are 1/4, so won't be the newest version.
Try install again.
BitShares committee member: abit
BitShares witness: in.abit

tonyk

Quote from: abit on January 26, 2016, 08:18:00 PM
Quote from: tonyk on January 26, 2016, 08:13:16 PM
@abit same results after the last instruction - rescan blockchain and all
I'm sure you're running with an old version.

Release date 1/04/2016

Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

abit

#10
Quote from: tonyk on January 26, 2016, 08:13:16 PM
@abit same results after the last instruction - rescan blockchain and all
I'm sure you're running with an old version.
BitShares committee member: abit
BitShares witness: in.abit

tonyk

@abit same results after the last instruction - rescan blockchain and all

@cube - yes I see connections to several seed nodes... on and off



104.236.144.84:1777,   -> 104.236.144.84:1777 last seen 2016-01-26T18:37:49

here are data from 3 different times later on... mostly non-seed nodes as far as I can tell.

TCP    xxx.154.1.146:58678    23-95-43-126-host:50696  ESTABLISHED
TCP    xxx.154.1.146:58678    45:1779                ESTABLISHED
TCP    xxx.154.1.146:58678    cpe-70-114-143-108:48173  SYN_SENT
TCP    xxx.154.1.146:58678    104.236.144.84:1777    TIME_WAIT
TCP    xxx.154.1.146:58678    114.92.254.159:62015   LAST_ACK
TCP    xxx.154.1.146:58678    115.29.36.189:35897    ESTABLISHED
TCP    xxx.154.1.146:58678    178.62.88.151:60335    TIME_WAIT
TCP    xxx.154.1.146:58678    witness:35718          LAST_ACK
TCP    xxx.154.1.146:58718    a23-72-60-161:https    CLOSE_WAIT


TCP    xxx.154.1.146:58678    162.243.138.215:40124  ESTABLISHED
TCP    xxx.154.1.146:58678    178.62.88.151:60335    ESTABLISHED

TCP    xxx.154.1.146:58678    li699-30:44223         ESTABLISHED
TCP    xxx.154.1.146:58678    69.30.232.146:52002    ESTABLISHED
TCP    xxx.154.1.146:58678    84.200.17.129:1779     ESTABLISHED
TCP    xxx.154.1.146:58678    104.236.144.84:1777    ESTABLISHED
TCP    xxx.154.1.146:58678    li611-150:42665        TIME_WAIT
TCP    xxx.154.1.146:58678    115.29.36.189:35897    ESTABLISHED


This one 84.200.17.129 from above is a  seed node. The communication went something like...

active: 84.200.17.129:1779 with 97ea3e6a4056decd6d44868e43cb444d883f875cebedfd00a48159a23a95c0b67f   [outbound]

eer 84.200.17.129:1779 because they didn't respond to my request for sync item ids after ["002b0e5966422ef475e20ef2c96acdaec7d51127","002b21e06bbd170a778f9cbc8891fa73f51764b1...

nnection.cpp:202
2016-01-26T19:00:36 p2p:message read_loop on_connection_closed ] Remote peer 84.200.17.129:1779 closed their connection to us

node.cpp:985
2016-01-26T19:00:36 p2p:message read_loop schedule_peer_for_de ] scheduling peer for deletion: 84.200.17.129:1779 (this will not block)

handshaking: 84.200.17.129:1779 with 000000000000000000000000000000000000000000000000000000000000000000  [unknown]

handshaking: 84.200.17.129:1779 with 97ea3e6a4056decd6d44868e43cb444d883f875cebedfd00a48159a23a95c0b67f  [outbound]
84.200.17.129:1779 last seen 2016-01-26T19:00:50




some active communications with some non-seed nodes
from p2p.log2016012T1800000

node.cpp:2522
2016-01-26T18:37:51 p2p:message read_loop fetch_next_batch_of_ ] sync: sending a request for the next items after 002b2d966b7cf344032b787762760e770e22c90d to peer 159.203.101.247:54765, (full request is ["002b0e5966422ef475e2...

node.cpp:2424
2016-01-26T18:37:51 p2p:message read_loop           on_message ] handling message blockchain_item_ids_inventory_message_type 57179945df4926db3b90931eafa6834ba1213ce8 size 40010 from peer 159.203.101.247:5
node.cpp:1754
2016-01-26T18:37:51 p2p:message read_loop on_blockchain_item_i ] sync: received a list of 2000 available items from 159.203.101.247:54765
node.cpp:1754
2016-01-26T18:37:51 p2p:message read_loop on_blockchain_item_i ] sync: received a list of 2000 available items from 159.203.101.247:54765


PS
and the witness node spit a new line (for the first time) after 2h or so later:
2095358ms ntp        ntp.cpp:177                   read_loop            ] ntp_de
lta_time updated to 950002 us
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

cube

#8
Quote from: tonyk on January 25, 2016, 06:07:47 PM
Thanks everyone.
1) I am running this
BitShares-2.0.160103b-x64-cli-tools.exe

It is the latest for win that I see up there. Is there newer version somewhere?

2)Specifically allowed the witness_node.exe through the firewall. (and turning it off completely - with same results)...
TCP    0.0.0.0:52122          Inspiron_i5:0          LISTENING



This is allowing port 52122. What about other ports? Are they opened? Do turn off firewall completely to eradicate this as a possible issue.

Quote from: tonyk on January 25, 2016, 06:07:47 PM
3) I believe I have a connection to this seed node:

TCP    xxx.156.1.146:52122    188.166.188.206:1779   ESTABLISHED

edit: I thought it was visible from the pic above but it seems not. anyway 188.166.188.206:1779   is one of the seed nodes witness_node.exe is trying to connect to.

What to try next? I believe I was running the witness node during the last hard fork time if this changes anything somehow.

Do you see other seed nodes established?   Once we know seeds and peers are communicating with your node, the next thing is to find out if they are indeed sending out information to it.
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

abit

Quote from: tonyk on January 25, 2016, 06:07:47 PM
Thanks everyone.
1) I am running this
BitShares-2.0.160103b-x64-cli-tools.exe

It is the latest for win that I see up there. Is there newer version somewhere?

2)Specifically allowed the witness_node.exe through the firewall. (and turning it off completely - with same results)...
TCP    0.0.0.0:52122          Inspiron_i5:0          LISTENING



3) I believe I have a connection to this seed node:

TCP    xxx.156.1.146:52122    188.166.188.206:1779   ESTABLISHED

edit: I thought it was visible from the pic above but it seems not. anyway 188.166.188.206:1779   is one of the seed nodes witness_node.exe is trying to connect to.

What to try next? I believe I was running the witness node during the last hard fork time if this changes anything somehow.
1. Reinstall BitShares-2.0.160103b-x64-cli-tools.exe and take a look at C:\Program Files\BitShares 2\bin\, make sure it's the newest one.
2. start witness_node.exe with parameter "--replay-blockchain"
BitShares committee member: abit
BitShares witness: in.abit

tonyk

#6
Thanks everyone.
1) I am running this
BitShares-2.0.160103b-x64-cli-tools.exe

It is the latest for win that I see up there. Is there newer version somewhere?

2)Specifically allowed the witness_node.exe through the firewall. (and turning it off completely - with same results)...
TCP    0.0.0.0:52122          Inspiron_i5:0          LISTENING



3) I believe I have a connection to this seed node:

TCP    xxx.156.1.146:52122    188.166.188.206:1779   ESTABLISHED

edit: I thought it was visible from the pic above but it seems not. anyway 188.166.188.206:1779   is one of the seed nodes witness_node.exe is trying to connect to.

What to try next? I believe I was running the witness node during the last hard fork time if this changes anything somehow.
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

abit

#5
Quote from: cube on January 25, 2016, 10:00:09 AM

A few things to check:

1) You are running the latest witness_node (what is the version release?)
2) Your firewall is not blocking witness_node (disable firewall temporary to check)
3) You are connected to at least one seed node and not blocked  (show result of command 'netstat -a' here).
I'm sure @tonyk is running with an old version. The newest version contains a hard fork logic at block #2821745 on Jan. 3.
BitShares committee member: abit
BitShares witness: in.abit

cube

#4
Quote from: tonyk on January 25, 2016, 05:40:14 AM
well, I run it as administrator as it is (I suppose using a link to do so will not change much), the problem is it just hangs ..after finding the longest chain to hook up to (something like 2.8 mil blocks as of Jan something)...it just hangs somewhere shortly after.


[edit]



A few things to check:

1) You are running the latest witness_node (what is the version release?)
2) Your firewall is not blocking witness_node (disable firewall temporary to check)
3) You are connected to at least one seed node and not blocked  (show result of command 'netstat -a' here).
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

tonyk

#3
Quote from: Xeldal on January 25, 2016, 05:02:05 AM
For Witness:
I make a shortcut with "C:\Program Files\BitShares 2\bin\witness_node.exe" --rpc-endpoint "127.0.0.1:8090"
as the target.
Run as Administrator

For wallet:
I make a shortcut with "C:\Program Files\BitShares 2\bin\cli_wallet.exe" -H 127.0.0.1:8092 -s ws://127.0.0.1:8090
as the target.
Run as Administrator

well, I run it as administrator as it is (I suppose using a link to do so will not change much), the problem is it just hangs ..after finding the longest chain to hook up to (something like 2.8 mil blocks as of Jan something)...it just hangs somewhere shortly after.


[edit]

Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

Xeldal

For Witness:
I make a shortcut with "C:\Program Files\BitShares 2\bin\witness_node.exe" --rpc-endpoint "127.0.0.1:8090"
as the target.
Run as Administrator

For wallet:
I make a shortcut with "C:\Program Files\BitShares 2\bin\cli_wallet.exe" -H 127.0.0.1:8092 -s ws://127.0.0.1:8090
as the target.
Run as Administrator

tonyk

#1
as per thread title - anybody able to run the latest witness node under windows and if 'yes', how?

Thanks.

@cube ...@pc  ?
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.