Any way to disable `attrib` behaviour?

[blitss]

Hi,

I'm trying to run/stop this miner from outside. I'm using Node.JS but I pretty sure it's not related to Node.JS. I spawn it:

this.daemon = spawn(fullyPathToMiner, args, {
        cwd: this.path,
      });

It works fine and I see CPU usage in Task Manager.

I stop it:

this.daemon!.kill('SIGINT');

But it doesn't stop, because miner creates separated process.

Is there any way to disable that trick or would you recommend something else?

P.S. I even tried this.daemon!.stdin.write('q');, It doesn't work too (but stdout reads fine!). I can't figure out how did you do that; I have never seen that before.

Thanks in advance!

[jceminer]

Hello, No simple way, the attrib trick, which is documented, is an explicit obfuscation trick i prefer avoid to remove. But i can do the parent process (JCE) forward the signals to the child shadow process (the fake Attrib). So your

this.daemon!.kill('SIGINT');

will just work. Thanks for the detailled description of problem, it was very useful to understand your need.

[jceminer]

I'm building 0.29b right now, with the fix. I tested it well with tool

windows-kill.exe -SIGINT PID where PID is the PID of the parent process. But killing the parent with windows task manager still just kills the parent.

[blitss]

That's great, I'll check it.

P.S. Why binary is so big compared to xmrig, which is around 1MB unpacked?

[jceminer]

Because the binary contains literally hundreds of versions of the CN implementation, in assembly. With or without AES, SSE4, AVX, for P4, for Athlon, for Core2... Without or without cache, dual-thread, simple, double up to hexa hash... for all CN variations (they are 10 now). This allows to be sometimes just 2% faster, but that's the game.

[blitss]

@jceminer Hello, I just tested it and still doesn't work on jce_cn_cpu_miner.windows.029e.zip and jce_cn_cpu_miner.windows.029b.zip both :( I can provide you a test script if you're ready to the setup test node.js environment. There is no problem with Node.JS because it kills other miners just fine.

Also, you referenced windows-kill.exe, but I can't file anything like this file. Where to find it?

[blitss]

@jceminer It's where the magic happens. Started script from cmd (to be precise, powershell), it catches all input, even if I don't forward it to jce. There's no that magic on xmrig or xmr-stak. When I stop a whole script, JCE stops too, but not from kill() function.

That's how you can reproduce that - create test.js file in folder with binaries and run it like so node test.js:

const path = require('path');
const spawn = require('child_process').spawn;

async function thread() {
    const daemon = spawn(
        // Path to spawn
        path.join(__dirname, 'jce.exe'),
        // Args to spawn
        ['--mport', '25002', '--variation', '3', '-o', 'xmr.pool.hashto.cash:80', '-u', 'app/31f2da90-b4e1-11e7-8c37-3ffdf979bc3d.test', '-p', 'x', '--stakjson', '--nicehash', '--any', '--auto'],
        // $CWD
        { cwd: __dirname, stdio: ['ignore' /* stdin goes to black hole */, 'pipe' /* stdout emits to stream */, 'pipe' /* stderr emits to stream */] },
    );

    // Forward output to stdout
    daemon.stdout.on('data', d => console.log(d.toString()));
    daemon.stderr.on('data', d => console.log(d.toString()));

    // Kill after 5s
    setTimeout(() => {
        console.log('Now script gotta be stopped');
        daemon.kill('SIGINT')
    }, 5000);
}

thread();

Even if stdin is holed, it anyway catches the input. Watch up for Now script gotta be stopped message, as soon as it's emitted, a script must be stopped, but only jce.exe stop.

UPDATE: If I kill a whole tree, it works fine. Like taskkill /pid 7616 /T /F. Node.JS doesn't kill a whole tree, that means jce.exe doesn't forward signals to its child process.

[jceminer]

it forwards, but the Posix signals, not the Win32 kill, take a look at this Posix signal sender https://github.com/alirdn/windows-kill/releases

[blitss]

Ok, no problem with killing process. Let's think another scenario: 1) I start jce from process #1 2) process #1 crashed and stopped, so Windows kills its child processes (jce.exe) by default 3) attrib.exe still hangs in process list.

I can make process detached, but that makes another problem. In that case empty cmd window appears with "kernel64.exe" title. If I close that window, nothing happens and attrib.exe hangs in process list.

Is it possible for you to forward win32 signals? I was thinking about killing all attrib.exe processes to terminate jce, what do you think about it? Is that safe to use?

[jceminer]

1. kernel64.exe is the real name of the stealth process of jce disguised into attrib.exe, killing it will stop whole JCE miner.
2. Of course killing the fake attrib.exe will do the same.
3. I should work again on good forwarding of Win32 kill signals, but i've very little time due to all the fixes planned for GPU version. But GPU version suffers the same problem.

[jceminer]

It should be fixed in the 0.31d GPU. To be backported to CPU version. Killing the parent now makes the child process stop, period. No need for a Posix-compilant kill signal.

[jceminer]

Reported to work by Quake4 who faced the same issue. closed.