mm.js spawning multiple child mining threads

[darknicht66]

It appears that mm.js is not cleanly killing the current mining thread before spawning a new thread when changing crypto alogorithms. Seen on all mm.js versions since just before the cn/2 fork.

When running mm.js, after a random amount of time (hours to days) it will eventually start to complain about 'connection already in use' and fail to submit any hashes. Looking at the pidtree of the 'node mm.js' process you can see two child processes of xmrig running. Killing mm.js and restarting it will allow it to continue working again.

I have seen this happen on both my Windows and Linux rigs, and spawning either xmrig or xmrig-nvidia.

I have begun testing with older commits of mm.js (0.8,0.9,1.1 and 1.2) on various machines to try and track down which commit this issue started with. I know the older version from late Aug (0.8?) did not show this. I will update this ticket if I can determine which commit needs closer inspection.

[darknicht66]

For clarity sake, here's a few snippets showing what is happening on a linux machine experiencing the 'multiple child process' issue...

miner@xmr0:~$ tail mm-cpu.log [2018-10-23 22:07:06] [localhost:3333] error: "Invalid job id", code: -1 [2018-10-23 22:07:13] [localhost:3333] error: "Invalid job id", code: -1 [2018-10-23 22:07:14] speed 10s/60s/15m n/a n/a n/a H/s max 170.6 H/s !!! Miner server on 127.0.0.1:3333 port is already connected (please make sure you do not have other miner running) [2018-10-23 22:07:21] [localhost:3333] error: "Invalid job id", code: -1 [2018-10-23 22:07:22] [localhost:3333] error: "Invalid job id", code: -1 !!! Miner server on 127.0.0.1:3333 port is already connected (please make sure you do not have other miner running) [2018-10-23 22:07:25] speed 10s/60s/15m 32.0 37.0 42.8 H/s max 54.2 H/s [2018-10-23 22:07:27] [localhost:3333] error: "Invalid job id", code: -1 !!! Miner server on 127.0.0.1:3333 port is already connected (please make sure you do not have other miner running)

miner@xmr0:~$ ps aux | grep mm.js | grep -v grep root 1946 0.0 2.3 1231868 23492 ? SNsl Oct20 1:13 /usr/bin/nodejs /home/miner/mm.js /home/miner/mm.json --log=/home/miner/mm-cpu.log

miner@xmr0:~$ ps --ppid 1946 PID TTY TIME CMD 40707 ? 00:00:51 xmrig-cpu 42163 ? 00:01:16 xmrig-cpu 58256 ? 11:30:00 xmrig-cpu 60311 ? 00:00:20 xmrig-cpu 62684 ? 11:20:47 xmrig-cpu

As you can see mm.js (PID 1946) currently has five child xmrig-cpu processes spawned rather than the max one process it should have at any time.

[darknicht66]

After running a bisect, it appears that bdd777f was the last stable version to work for me. I have had 6 instances of that commit running for >40 hours without failure. None of the later commits (tested up to 6b4530b) lasted more than 24 hours without at least one instance failing. This would point to commit a92a6d4 as being the offender. I'll continue testing, and update this ticket if I see any change in behaviour (there is the possibility I just hit a 40 hour lucky streak.)

[darknicht66]

No issues after a further 48 hours of testing on bdd777f for all of my rigs. Bisect says the issue was introduced in a92a6d4

[darknicht66]

I have been testing 5e03d82 for several days now with no issues. This bug appears to have been squashed with the latest code.