Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any way to disable attrib behaviour? #7

Closed
blitss opened this issue May 31, 2018 · 11 comments
Closed

Any way to disable attrib behaviour? #7

blitss opened this issue May 31, 2018 · 11 comments

Comments

@blitss
Copy link

blitss commented May 31, 2018

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.
image

I stop it:

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

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

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
Copy link
Owner

jceminer commented Jun 2, 2018

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
Copy link
Owner

jceminer commented Jun 2, 2018

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
Copy link
Author

blitss commented Jun 2, 2018

That's great, I'll check it.

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

@jceminer
Copy link
Owner

jceminer commented Jun 2, 2018

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 blitss closed this as completed Jun 6, 2018
@blitss
Copy link
Author

blitss commented Jun 29, 2018

@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 blitss reopened this Jun 29, 2018
@blitss
Copy link
Author

blitss commented Jun 29, 2018

@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
Copy link
Owner

jceminer commented Jul 6, 2018

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
Copy link
Author

blitss commented Jul 7, 2018

Ok, no problem with killing process. Let's think another scenario:

  1. I start jce from process socks support #1
  2. process socks support #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
Copy link
Owner

jceminer commented Jul 7, 2018

  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
Copy link
Owner

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
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants