Closed deh8551 closed 6 years ago
smurfy
commented
6 years ago � ℹ �13:32:39��|�stratum ��|�� Authorized worker deh.xx1�
The thing is, you are authorized by the server, you just dont get any work for some reason.
You can try what i suggested in #1111 combine -P exit and a low --work-timeout setting.
Which should work.
deh8551
commented
6 years ago The combination of those switches does successfully kill the miner when there is no work to perform so that is an option.
I also ran some packet captures using the latest git version and the previous version (0.14.0rd5+git.a0a3d21) that seems to honor the unauthorized message from miningpoolhub. When an alternate algo has a higher priority at miningpoolhub for the algo switching, miningpoolhub does appear to be sending the result false to the mining.authorize query when ethminer starts.
{"id":1,"jsonrpc":"2.0","method":"mining.subscribe","params":[]} {"id":1,"result":[[["mining.set_difficulty","deadbeefcafebabe9ca9000000000000"],["mining.notify","deadbeefcafebabe9ca9000000000000"]],"48006c54",4],"error":null} {"id":3,"jsonrpc":"2.0","method":"mining.authorize","params":["deh8551.hw3a","x"]} {"id":3,"result":false,"error":null}
and when ethereum is the highest priority, it is sending the result true stating the account is authorized.
{"id":1,"jsonrpc":"2.0","method":"mining.subscribe","params":[]} {"id":1,"result":[[["mining.set_difficulty","deadbeefcafebabe99a9000000000000"],["mining.notify","deadbeefcafebabe99a9000000000000"]],"08006bae",4],"error":null} {"id":3,"jsonrpc":"2.0","method":"mining.authorize","params":["deh8551.hw3a","x"]} {"id":3,"result":true,"error":null} {"id":null,"method":"mining.notify","params":["b56","0xe4aaec40bce69f1b413739a7648dc072a5f2c66f9930c3a854eb2c78cafc8d60","0xe6073b5528bd0132af704e709c5723848c28e74e1d250eff85fc89e916b8515e","0x00000000ffb34c02420e9948eacd78cf33b059a88ade1ff0614f7f3c303cf3a7",true]}
Version 0.14.0rd5+git.a0a3d21 seems to honor result response, but the later versions seem to assume the miner is authorized even though it’s not.
smurfy
commented
6 years ago {"id":3,"result":false,"error":null}
is the magic bit, in current stratum implementation its handled as success if result is not null.
So my guess is we should handle that aswell as error, at least in handling the "mining.authorize" method. what do you think @AndreaLanfranchi ?
AndreaLanfranchi
commented
6 years ago {"id":3,"result":false,"error":null}
As @smurfy already pointed out this is the issue. This response is a RPC V1 syntax and, as clearly stated in the specifications, in case of "negative response" the member "result" must be null. Here, instead, the push out it to be "false" and also they do not give any reason in the "error" member (which should be an object) about the failure.
We need to arrange some tricks to handle all the crap implementations of stratum out there.
smurfy
commented
6 years ago In my opinion its within the specs. Its no error, you are just not authorised. Which is reflected by the false in the result field.
As i understand the spec it should be NULL if an error occurs but man can argue that a failed authorisation is not an protocol error but an application error which is handled differently per method invoked.
In case of the mining.authorize method a true means authorised and a false mean not authorised. This status is returned in the result field on the protocol layer. (json-rpc)
So i would handle the result parsing on a per method level not globally.
Edit:
This must be null in case there was an error invoking the method.
If you read the spec its quite clear, there was no error invoking the method.
The application logic the method performed was just not successful. aka authorising the user.
AndreaLanfranchi
commented
6 years ago This is not a protocol error but a logic error. All jsonrpc is about request/response. When a client issues a request the server sends back a response which states wether or not that request was valid/executable/extecuted and generated a valid result.
As per my understanding the "mining.subscribe" request is valid (in the sense it is properly formatted) but it's values do not allow the request to be fulfilled (maybe invalid account ?). For this reason server should respond (according to specs) with
{"id":3,"result":null,"error": {"code": xxx, "reason": "Invalid login"}}
I am absolutely sure pool's implementation of this response is absolutely wrong. Nevertheless, aside the presence of the scarse jsonrpc.org, I must admit there is no de facto standard in implementing a proper jrpc syntax thus we must keep up for all the rubbish out there.
I would not implement something at "request type" level (as you suggested only for "mining.subscribe") as this creates a such high degree of possible exceptions that is impossible to bisect.
We must fall back into a case wether the "success" in response must pass through an evaluation of member type: if it's boolean than act accordingly.
AndreaLanfranchi
commented
6 years ago
- result - The Object that was returned by the invoked method. This must be null in case there was an error invoking the method.
- error - An Error object if there was an error invoking the method. It must be null if there was no error.
- id - This must be the same id as the request it is responding to.
The magic word is "invoking" : this implies an error anywhere in the complete call stack. From sanity checks over syntax up to expected result.
AndreaLanfranchi
commented
6 years ago In case of the mining.authorize method a true means authorised and a false mean not authorised. This status is returned in the result field on the protocol layer. (json-rpc)
This is an "intepretation" ... not a rule. So why other pools act properly ?
smurfy
commented
6 years ago We must fall back into a case wether the "success" in response must pass through an evaluation of member type: if it's boolean than act accordingly.
In my opinion its up to the implementer of the application logic (stratum) if they should raise an json-rpc error or handle it via application logic. In case of this stratum logic they choose to use application logic.
I would suggest the following. In https://github.com/ethereum-mining/ethminer/blob/master/libpoolprotocols/stratum/EthStratumClient.cpp#L745
Change that the application logic result is parsed too. Meaning check the value of result.
We are probably fine interpreting it as bool. Same is for mining.submit
For reference one of the stratum specs: (they also talk about false/true as possible result) https://en.bitcoin.it/wiki/Stratum_mining_protocol
as this creates a such high degree of possible exceptions that is impossible to bisect.
Well apart of i think you mixed mining.subscribe and mining.authorize. We only actually handle submit and authorize results. mining.subscribe has a bunch of results (array) but its not handled at all.
Edit: And if its no error, i would say we MUST handle the result on a per method basis, since its application logic. And the result differs per method. JsonRpc is just the transport protocol after all. Luckly we only care about the subscribe and authorize result.
AndreaLanfranchi
commented
6 years ago Well apart of i think you mixed mining.subscribe and mining.authorize
I don't get this. Could elaborate ?
smurfy
commented
6 years ago I don't get this. Could elaborate ?
nothing important, you wrote mining.subscribe in your earlier comment, but the problem is with mining.authorize and i think you meant the same thing, (you write id 3, and login failed) just mixed up the method names.
We do not actually parse/handle the results of mining.subscribe, because we get the info present there as separate "notification" messages from the pool
AndreaLanfranchi
commented
6 years ago mining.subscribe has a bunch of results (array) but its not handled at all.
That's not true ... mining.subscribe response has a additional parameters in ETHEREUMSTRATUM mode and they're handled.
In STRATUM only mode mining.subscribe does not send back anything aside the result (positive or negative) to the subscription. It's necessary, afterwards, to get authorized.
smurfy
commented
6 years ago That's not true ... mining.subscribe response has a additional parameters in ETHEREUMSTRATUM mode and they're handled.
ah ok, missed that, i referred the other stuff described here: https://en.bitcoin.it/wiki/Stratum_mining_protocol#mining.subscribe
Edit: But this confirms my point/argument, that just because it succeeded on protocol level, we also need to check it on application/method level.
AndreaLanfranchi
commented
6 years ago Edit: But this confirms my point/argument, that just because it succeeded on protocol level, we also need to check it on application/method level.
I am not arguing but i really do not understand your point. Jsonrpc is protocol and application at the same time. Rules for positive/negative responses are well depicted. If server sends back a "negative" response to my request (no matter if due to the fact is badly formed, or choronologically wrong, or ... again, if there is an authentication error on servers' backend) it should compose it following the rules for an "error" response thus putting result to null and error to whatever is meaningful to help me amend that error.
From a response like this
{"id":3,"result":false,"error":null}
what are we supposed to understand ?
Help me understand.
Result = null is meant like "Sorry I cannot give you any result to your request because the request itself causes an error. I should also clarify in "error" member which error is ... but apparently I am too lazy to tell you"
smurfy
commented
6 years ago I am not arguing but i really do not understand your point.
Hehe sorry, about that. I try to make it clearer. For me jsonrpc is just a transport protocol.
RPC means remote procedure call, so its a RPC using JSON.
Part of the json rpc spec is, that messages can be send both ways. A request and a response can be mainly separated by, that an request contains a method (the procedure to call) and params (arguments to that method). Responses contain the result, which contains method specific, out of scope of jsonrpc data. And an error element which should contain error or null
The spec also specifies in case of an error, that result needs to be null.
Thats all everything else is application logic and out of scope of the json rpc spec and is handled by client/server code on a method level.
Also since result can be also be null (as per spec) in case of no error (error is null) i would not use it to detect if the call was successful at all. If the method returns data its in the result field. And the client needs to handle the result based on the method called. Since each method can, and does in stratum, returns different data.
For your questions:
Is it a termporary error on server's side ?
depends, again on the method. If there is a method lets say. doYouHaveWork it can return a boolean which is false or true. But thats again dependent on the method
Is it fatal ? Should I retry ?
depends whats the application logic spec, stratum requires. In our case with mining.authorize we probably should disconnect. But another client could prompt for another password.
Did I send a malformed request ?
nope. malformed requests, are protocol level, so in case of that the error response field should be set.
Is data in the request not compliant to some validating rule ?
this depends on how the application spec specifies how to handle validation errors. In my opinion i probably prefer the error field, but a defined validation failed result can be also possible.
Result = null is meant like "Sorry I cannot give you any result to your request because the request itself causes an error.
No result = null is not an error, maybe the method only consumes data and returns nothing, which is totally fine and within the spec of json-rpc.
SnowLeopard71
commented
6 years ago 0.15.0-dev10 with bad user on ethermine gives:
ℹ 13:00:02|stratum | Worker not authorized: Invalid user provided
but loops infinitely trying the same thing over and over expecting a different result.
Only one server provided on the commandline, so it is not iterating through failover servers.
ethminer should always shutdown when mining.authorize returns a result = false. Even if the error is included, we have to assume the server is working properly and not having an temporary outage and the result is accurate, in which case there is no point in continuing. If ethminer were an interactive client, then it would prompt the user for new credentials before retrying.
Also (from json-rpc 1.0): result - The Object that was returned by the invoked method. This must be null in case there was an error invoking the method.
The stratum spec only says The result from an authorize request is usually true (successful), or false. The password may be omitted if the server does not require passwords. about the response. There is no mention of providing reason for failure in the error part of the response.
IMO, any result other than true should be a terminal error. If multiple servers are provided on the commandline, then each should be tried once and if all fail mining.authorize, ethminer should terminate.
SnowLeopard71
commented
6 years ago Patch fixes how ethminer interprets result from miningpoolhub -- now logs:
ℹ 12:29:26|stratum | Worker not authorized BADNAME
ethminer still goes into endless loop, regardless of whether --exit is used, but the script in OP should catch the message and kill ethminer.
smurfy
commented
6 years ago use -P exit or -P stratum+tcp://exit:1
As i mentioned before --exit is for OPENCL/CUDA errors NOT for pool errors.
I tested the -P variant and it 100% works.
SnowLeopard71
commented
6 years ago -P exit gives an error and the other still loops infinitely using ./ethminer/ethminer -U -P stratum+tcp://BADNAME:x@us-east.ethash-hub.miningpoolhub.com:12020 -P stratum+tcp://exit:1
Help output needs improvement: --exit Stops the miner whenever an error is encountered appears among pool/stratum options, and the wording is not specific enough.
smurfy
commented
6 years ago what version do you use? Works for me:
m 20:17:02|main | ethminer 0.15.0.dev10-11+commit.da3aeb5e.dirty
m 20:17:02|main | Build: windows / release
cu 20:17:02|main | Using grid size 8192 , block size 128
i 20:17:03|main | Selected pool us-east.ethash-hub.miningpoolhub.com:12020
m 20:17:03|main | not-connected
i 20:17:03|stratum | Trying 34.237.153.159:12020 ...
i 20:17:03|stratum | Connected to us-east.ethash-hub.miningpoolhub.com [34.237.153.159:12020]
i 20:17:03|stratum | Spinning up miners...
i 20:17:03|cuda-0 | No work. Pause for 3 s.
i 20:17:03|stratum | Subscribed to stratum server
i 20:17:03|stratum | Worker not authorized BADNAME
i 20:17:03|stratum | Disconnected from us-east.ethash-hub.miningpoolhub.com [34.237.153.159:12020]
i 20:17:03|stratum | Shutting down miners...
i 20:17:06|stratum | Retrying in 3 ...
i 20:17:07|stratum | Retrying in 2 ...
m 20:17:08|main | not-connected
i 20:17:08|stratum | Retrying in 1 ...
i 20:17:09|stratum | Selected pool us-east.ethash-hub.miningpoolhub.com:12020
i 20:17:09|stratum | Trying 34.237.153.159:12020 ...
i 20:17:09|stratum | Connected to us-east.ethash-hub.miningpoolhub.com [34.237.153.159:12020]
i 20:17:09|stratum | Spinning up miners...
i 20:17:09|cuda-0 | No work. Pause for 3 s.
i 20:17:09|stratum | Subscribed to stratum server
i 20:17:09|stratum | Worker not authorized BADNAME
i 20:17:09|stratum | Disconnected from us-east.ethash-hub.miningpoolhub.com [34.237.153.159:12020]
i 20:17:09|stratum | Shutting down miners...
i 20:17:12|stratum | Retrying in 3 ...
m 20:17:13|main | not-connected
i 20:17:13|stratum | Retrying in 2 ...
i 20:17:14|stratum | Retrying in 1 ...
i 20:17:15|stratum | Selected pool us-east.ethash-hub.miningpoolhub.com:12020
i 20:17:15|stratum | Trying 34.237.153.159:12020 ...
i 20:17:15|stratum | Connected to us-east.ethash-hub.miningpoolhub.com [34.237.153.159:12020]
i 20:17:15|stratum | Spinning up miners...
i 20:17:15|cuda-0 | No work. Pause for 3 s.
i 20:17:15|stratum | Subscribed to stratum server
i 20:17:15|stratum | Worker not authorized BADNAME
i 20:17:15|stratum | Disconnected from us-east.ethash-hub.miningpoolhub.com [34.237.153.159:12020]
i 20:17:15|stratum | Shutting down miners...
m 20:17:18|main | not-connected
i 20:17:18|stratum | Retrying in 3 ...
i 20:17:19|stratum | Retrying in 2 ...
i 20:17:20|stratum | Retrying in 1 ...
i 20:17:21|stratum | Selected pool us-east.ethash-hub.miningpoolhub.com:12020
i 20:17:21|stratum | Trying 34.237.153.159:12020 ...
i 20:17:21|stratum | Connected to us-east.ethash-hub.miningpoolhub.com [34.237.153.159:12020]
i 20:17:21|stratum | Spinning up miners...
i 20:17:21|cuda-0 | No work. Pause for 3 s.
i 20:17:21|stratum | Subscribed to stratum server
i 20:17:22|stratum | Worker not authorized BADNAME
i 20:17:22|stratum | Disconnected from us-east.ethash-hub.miningpoolhub.com [34.237.153.159:12020]
i 20:17:22|stratum | Shutting down miners...
m 20:17:23|main | not-connected
i 20:17:24|stratum | Retrying in 3 ...
i 20:17:25|stratum | Retrying in 2 ...
i 20:17:26|stratum | Retrying in 1 ...
i 20:17:27|main | Exiting because reconnecting is not possible.
i 20:17:27|main | Shutting down...Apologies, I was not waiting long enough for it to terminate on it's own.
deh8551
commented
6 years ago Change #1114 that was just added has corrected it issue. The miner is again exiting when the worker is not authorized. Thank you.
smurfy
commented
6 years ago happy to hear
deh8551
commented
6 years ago @yorper The script requires the ‘expect’ package to be installed. It uses the unbuffer utility from it.
On May 19, 2018, at 10:28 PM, Yorper notifications@github.com wrote:
@deh8551 https://github.com/deh8551 i've tried to use your launch script as it appears far superior to mine, but i keep getting the following errors in a never ending loop for all mining apps, any ideas?
couldn't execute "${HOME}/xminr-nv/ethminer": no such file or directory while executing "spawn -noecho {${HOME}/xminr-nv/ethminer} --farm-retries 0 --work-timeout 1 -U -P stratum+tcp://user.name:x@us-east.ethash-hub.miningpoolhub.com:1..." ("eval" body line 1) invoked from within "eval [list spawn -noecho] [lrange $argv 1 end]" invoked from within "if {[string compare [lindex $argv 0] "-p"] == 0} {
pipeline
set stty_init "-echo" eval [list spawn -noecho] [lrange $argv 1 end] clo..." (file "/usr/bin/unbuffer" line 13)— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ethereum-mining/ethminer/issues/1112#issuecomment-390453032, or mute the thread https://github.com/notifications/unsubscribe-auth/AiGILhEoAf-C3r177JzziRI_qb_amQIpks5t0NTVgaJpZM4T85QQ.
Yorper
commented
6 years ago @deh8551 Thanks, that got it going. Just curious also, how long does the script let something run for before terminating the application as for me it doesnt seem to ever terminate when any of the error phrases are produced? Thanks.
deh8551
commented
6 years ago @yorper it depends on the hub workers settings you have configured in miningpoolhub and the profitability they determine for the algorithm and card type. AMD cards tend to spend most of their time on Ethash/Ethereum and nvidia cards seems to move between equihash, lyra2re2, and skein mostly.
On May 22, 2018, at 1:54 AM, Yorper notifications@github.com wrote:
@deh8551 https://github.com/deh8551 Thanks, that got it going. Just curious also, how long does the script let something run for before terminating the application as for me it doesnt seem to ever terminate when any of the error phrases are produced? Thanks.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ethereum-mining/ethminer/issues/1112#issuecomment-390871605, or mute the thread https://github.com/notifications/unsubscribe-auth/AiGILqoHcxFk0ciIRkNZIVU-FVj_NE8mks5t06gygaJpZM4T85QQ.
Yorper
commented
6 years ago @deh8551 Thanks for the replies. It seems to be mostly working now, however The script doesn't seem to terminate my zec miner (i added a few extra miners) once it loses connection to MPH, it loops. I've changed the error phrases to match but nothing.... Am i not understanding correctly what your script does?
deh8551
commented
6 years ago @yorper If the script is seeing the termination message from the zec miner, for some like sgminer you have to add the verbose flag then the miner should be killed unless for some reason it’s respawning itself with a different PID that’s not being killed, but I’m not sure what you mean by loops.
On May 23, 2018, at 12:49 AM, Yorper notifications@github.com wrote:
@deh8551 https://github.com/deh8551 Thanks for the replies. It seems to be mostly working now, however The script doesn't seem to terminate my zec miner once it loses connection to MPH, it loops. I've changed the error phrases to match but nothing.... Am i not understanding correctly what your script does?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ethereum-mining/ethminer/issues/1112#issuecomment-391219200, or mute the thread https://github.com/notifications/unsubscribe-auth/AiGILrqURi9d_l8xWl-MvJmBvjROYY7uks5t1OpLgaJpZM4T85QQ.
tomose
commented
6 years ago Seeing the same issue that @Yorper is seeing with miningpoolhub. No exit.
ethminer_0.16.0.dev0.exe -U -P stratum2+tcp://username.worker-1:x@us-east.ethash-hub.miningpoolhub.com:12020 -P stratum+tcp://exit:1 --farm-retries 1 --work-timeout 1
i 16:57:10 main Selected pool us-east.ethash-hub.miningpoolhub.com:12020 m 16:57:10 main not-connected i 16:57:10 stratum Trying 18.204.40.75:12020 ... i 16:57:10 stratum Connected to us-east.ethash-hub.miningpoolhub.com [18.204.40.75:12020] i 16:57:10 stratum Spinning up miners... i 16:57:10 cuda-0 No work. Pause for 3 s. i 16:57:10 stratum Subscribed to stratum server i 16:57:10 stratum Extranonce set to 1ce4 (nicehash) i 16:57:10 stratum Worker not authorizedusername.worker-1 i 16:57:10 main Disconnected from us-east.ethash-hub.miningpoolhub.com [18.204.40.75:12020] i 16:57:11 main Selected pool us-east.ethash-hub.miningpoolhub.com:12020 i 16:57:11 stratum Trying 18.204.40.75:12020 ... i 16:57:11 stratum Connected to us-east.ethash-hub.miningpoolhub.com [18.204.40.75:12020] i 16:57:11 stratum Subscribed to stratum server i 16:57:11 stratum Extranonce set to 1479 (nicehash)
This goes on indefinitely.
I don't see why the program can't simply exit if it deems that the worker is not authorized. It knows enough to generate the message so in that same check can it not exit as well?
jmarunix
commented
6 years ago Well, I have the same issue that @tomose and @Yorper with the linux ethminer. I have done a little python script for that, running parallel, maybe anyone could export to windows miner:
ethminer_cmd = ['/usr/bin/pidof', 'ethminer']
while True:
PIDS=subprocess.run(ethminer_cmd, stdout=subprocess.PIPE, encoding='utf8').stdout.split()
if PIDS != []:# ethminer runs...now its control with strace
strace_cmd = "strace -e trace=write -s 150 -f -p " + PIDS[0]
hilo_strace = subprocess.Popen(strace_cmd.split(), stderr=subprocess.PIPE, encoding='utf8')
while True:
output = hilo_strace.stderr.readline()
if output == '' and hilo_strace.poll() is not None:
break
if output:
entradas = re.split("\n+", output)
if re.search("Worker not authorized",entradas[0]):
hilo_strace.kill()
os.kill(int(PIDS[0]), signal.SIGINT)
time.sleep(3)
When connecting to miningpoolhub using the multialgo settings, ethminer does not exit when the account is not authorized. Ethminer assumes it's authorized even though it's not and continues to report "No work" until killed . This began after issue #1038. Prior to that, ethminer exited as correctly when the account was not authorized. In this log instance, Skein was authorized, but ethash was not.
Here is the launch command:
!/bin/bash
MINER NAME
NAME=deh.xx1
export GPU_FORCE_64BIT_PTR=1 export GPU_MAX_HEAP_SIZE=100 export GPU_USE_SYNC_OBJECTS=1 export GPU_MAX_ALLOC_PERCENT=100 export GPU_SINGLE_ALLOC_PERCENT=100
BINARY DIRECTORY
BINDIR='/usr/local/bin' ETHBINDIR='./ethminer/build/ethminer'
START LOOP
while [ 1 ]; do
Ethash
(PIDFILE=$(mktemp /tmp/foo.XXXXXX) && trap "rm $PIDFILE" 0 \ && { (unbuffer ${ETHBINDIR}/ethminer --display-interval 15 --exit --cl-local-work 256 --cl-global-work 18432 --cl-parallel-hash 2 --cl-kernel 1 -G -P stratum+tcp://${NAME}:x@us-east.ethash-hub.miningpoolhub.com:12020 --farm-retries 0 ) \ 1> >(tee >(grep -q "Worker not authorized|Socket read failed|Shutting down miners" && kill $(cat $PIDFILE)) >&1) \ & PID=$! && echo $PID >$PIDFILE ; wait $PID || true; })
Equihash
(PIDFILE=$(mktemp /tmp/foo.XXXXXX) && trap "rm $PIDFILE" 0 \ && { (unbuffer ${BINDIR}/sgminer -T -v --thread-concurrency 16385 --xintensity 5 --worksize 256 --gpu-threads 4 -k equihash -o stratum+tcp://us-east.equihash-hub.miningpoolhub.com:12023 -O ${NAME}:d=2000) \ 1> >(tee >(grep -q "stratum auth failed|not responding!" && kill $(cat $PIDFILE)) >&1) \ & PID=$! && echo $PID >$PIDFILE ; wait $PID || true; })
Skein
(PIDFILE=$(mktemp /tmp/foo.XXXXXX) && trap "rm $PIDFILE" 0 \ && { (unbuffer ${BINDIR}/sgminer -T -v --intensity d --worksize 128 --gpu-threads 2 -k skeincoin -o stratum+tcp://hub.miningpoolhub.com:12016 -O ${NAME}:d=20) \ 1> >(tee >(grep -q "stratum auth failed|not responding!" && kill $(cat $PIDFILE)) >&1) \ & PID=$! && echo $PID >$PIDFILE ; wait $PID || true; }) done
exit 0
Here is the log: