keep getting this error -- > no active pools, stop mining about xmrig

[SlavisaBakic]

bug still pressent in version 6.21.0 of xmrig , running on mac m3 pro and windows10

023-12-05 00:36:05.752] miner speed 10s/60s/15m 2393.0 2376.3 2611.0 H/s max 2882.0 H/s [2023-12-05 00:37:04.153] net no active pools, stop mining [2023-12-05 00:37:05.879] miner speed 10s/60s/15m 1936.3 2330.4 2597.7 H/s max 2882.0 H/s [2023-12-05 00:37:11.547] net use pool randomxmonero.auto.nicehash.com:443 TLSv1.3 [2023-12-05 00:37:11.547] net fingerprint (SHA-256): "" [2023-12-05 00:37:11.547] net new job from randomxmonero.auto.nicehash.com:443 diff 131076 algo rx/0 height 134443 [2023-12-05 00:38:06.056] miner speed 10s/60s/15m 2355.8 2084.8 2548.2 H/s max 2882.0 H/s [2023-12-05 00:38:32.277] net no active pools, stop mining [2023-12-05 00:38:38.466] net use pool randomxmonero.auto.nicehash.com:443 TLSv1.3 198.18.0.145 [2023-12-05 00:38:38.466] net fingerprint (SHA-256): "a7bc29017c3d564fdbfd3e984891f"

Please ignore spam message above. Please try another mining pool and see if same problem persist. If not, it is issue on NiceHash side.

[geekwilliams]

@StelimslimDEV mate your site appears to be down. You sure it's not spam?

@SlavisaBakic has the best answer.

[viponedream]

same issue, some pool have this issue,
the miner should keep longer to wait for notify
the pool still send data, just slower some time.

[koitsu]

same issue, some pool have this issue, the miner should keep longer to wait for notify the pool still send data, just slower some time.

This might be configurable through the currently-undocumented --daemon-job-timeout flag (or in JSON config, daemon-job-timeout parameter in the pool section). The value is in milliseconds and defaults to 15000 (i.e. 15 seconds). I will be submitting a PR for the author to update documentation to reflect this flag/parameter.

However, I cannot immediately tell from the XMRig source code whether or not this would apply to the OP's situation, as it's clear more than 15 seconds has transpired between new job + report of "no active pools". Packet captures would ultimately tell what is going on (and plaintext is preferred for this, as TLS-based connectivity cannot be reviewed for payload request/response behaviours).