Feature Request: Graceful shutdown and graceful restart option

[nutsnax]

I hope this is in the right place... but I have a feature request for xmrig-proxy....

A graceful shutdown/restart option whereby when the shutdown request is received, xmrig-proxy 'waits' for workers to finish up their work and then stops accepting work from them.

Process flow example using 2 mining rigs connecting to a proxy:

Graceful shutdown/restart request received:

1. echo "Shutdown request received... waiting for rigs to finish up...."
2. Rig Instructions  #1 submits share, further shares blocked from that worker
3. Proxy knows 2 rigs are connected and waits for final share from Rig What is that #2
4. Rig What is that #2 submits share, xmrig-proxy blocks further shares and shuts down/restarts

Configurable option "Timeout" : Wait X number of seconds for shares when shutdown received.

Hopefully self-explanatory why I'm asking for this... but I'll explain anyway:

The idea here being that when the shutdown/restart request is received, the miners aren't losing the work they are currently doing.

[xmrig]

In next version (2.5) will be added graceful reload (config reload without loosing state) but there no reason for waiting, mining work is pure random here is no any kind of final share. One true solution is switch job as fast as possible.
Thank you.

[xmrig]

In dev branch added graceful reload support, more details: #119

[xmrig]

More details about remote configuration change #40 (comment)

[nutsnax]

I'm working with dev branch... getting this error:

[xmrig]

I figured it out, it expired share, itself it not issue and sometimes happen.
Please note this share will lost anyway, bug is only it bypassed to upstream pool. I will fix it later today.
Thank you.

[xmrig]

Fixed.

[nutsnax]

could it be possible to send 'old shares' received after the switch to the previous pool?

[xmrig]

It possible, but required non trivial logic to track both connections new one and old one for some time, but in worst case on few second can be loose (network latency + miner latency, especially for GPU).
Thank you.

[nutsnax]

I think the original way I thought this would work is to essentially wait for shares to come in per connection and upon receipt of a share from an 'old' pool, send the share to the old pool and redirect the connection to the new one. If it can work this way that would be awesome. Thanks for your help I appreciate it!