Hashtopolis Forum
HC already running on pid - Printable Version

+- Hashtopolis Forum (https://hashtopolis.org)
+-- Forum: Support (https://hashtopolis.org/forum-1.html)
+--- Forum: Problems (https://hashtopolis.org/forum-2.html)
+--- Thread: HC already running on pid (/thread-207.html)



HC already running on pid - robocop - 03-25-2019

Hi,
i upgraded to hashtopolis 0.10.1 (python3-Agent) on ubuntu 18.04.2 LTS (server and clients)
My problem happens with different hashcat-versions (4.2.1, 5.0.0, 5.1.0 tested).
The clients have 8 GTX1080 installed each.

The clients become paused very fast (usually even after speed test).
Error message is always HC: already running on pid ...
When i  check the shown pid, it does not exist any more.

I am trying to crack a truecrypt container password (mode 6213).

Any help is highly welcome!


RE: HC already running on pid - s3in!c - 03-25-2019

Do you have some debug output from the client when this happens?

Is there any other hashcat process running on the client during this time (which is not from hashtopolis)?


RE: HC already running on pid - robocop - 03-25-2019

client.log is attached.

There is no other hashcat process running on the same client.

Thanks for your help!


RE: HC already running on pid - hops - 03-26-2019

It looks like there was a problem shutting down hashcat correctly. Either that or the agent didn't wait long enough before starting the next command.
The restart happened because of the piping feature which automatically tries to optimize the attack.
[2019-03-25 14:12:20,365] [INFO ] Detected low UTIL value, restart chunk with piping..

To disable it you can add "allow-piping": false to your agent's config file.


RE: HC already running on pid - s3in!c - 03-26-2019

When doing a restart because of a low util value, it waits until Hashcat quit before it restarts the chunk with piping, also in the timestamp there around 1 sec in between, so it shouldn't be the problem. Maybe it's Hashcat which does not cleanup it's pid file before quitting or not checking it correctly (but I doubt that this is the case).

Something else is strange here.. Except the first status the util always is at 99%, so it should not even do the restart because of the util value as it needs to be lower than that.