Rogue processes when using chess engines

[Jesse Gersenson]

I've never seen or heard of this before with Komodo or Stockfish.

I duplicated the problem in Linux:

1. wine Arena.exe
2. click 'analysis' icon which started Komodo 9.1 (2 threads)
3. pkill Arena.exe

'top' shows Komodo's still running.

Graham, where does the 'terminatehard=true' get added, say for Komodo 9.1?

[hgm]

Well, wine is not really Linux. If wine is to emulate Windows faithfully, it would of course also emulate any Windows problems. What is a problem in one situation can be relied-upon behavior in others, and there is no way for wine to know that.

[MikeGL]

I've never seen or heard of this before with Komodo or Stockfish.

I duplicated the problem in Linux:

1. wine Arena.exe
2. click 'analysis' icon which started Komodo 9.1 (2 threads)
3. pkill Arena.exe

'top' shows Komodo's still running.

Graham, where does the 'terminatehard=true' get added, say for Komodo 9.1?

Seems to be normal if we just use pkill without properly exiting Arena.
I experimented with Arena and multiple UCI engines just now in Windows
(I have XP). Run Arena, Load any UCI Engine, open Taskmgr.exe then
choose "End Process" for Arena. You will notice the UCI engine will
become an orphaned process. The UCI engine will still be running, being
orphaned and will still use all resources provided by the OS.

Almost all UCI engines I checked have this behavior. They won't quit if Arena is manually killed.
So I guess it will be a good rule of thumb that if your GUI board freezes or
hangs, manually kill the GUI and don't forget to also manually kill all UCI
engines spawned by the GUI.

[hgm]

For native Linux engines this problem would not exist. Because writing into a Linux pipe where the only process on the reading end has died causes a fatal termination signal in the writing process. So if the GUI end of the pipe dies, sooner or later the analyzing engine will try to print a new PV, which will then cause its demise. Reading from a broken pipe will cause an end-of-file result, and it is up to the engine how it treats that. (Not an automatic termination by the OS.) I think that is also true for Windows pipes, but some engines do not read when they are thinking or pondering, so they might not notice this condition. (Engines that use a separate input thread would notice it, but not if they just poll for pending input.) In that case, if they also do not produce output, they would even hang (possibly using CPU forever) in Linux, in absence of forceful killing.

[MikeGL]

Thanks for this info regarding housekeeping of Linux in the background.

I just experimented with Windows again, If I right click Arena (inside Taskmgr.exe) then select "End Process Tree" it will include all UCI engines and other child processes of Arena. I am sure there is also a similar switch for kill and pkill in Linux where all child processes are also killed.

In windows command prompt the /T switch kills the whole tree (which means all UCI engines in Arena will be killed too):

C:\ Taskkill /T Arena.exe

[Graham Banks]

I refuse to believe it doesn't happen to most users as well.

I've never seen or heard of this before with Komodo or Stockfish.

Nor have I.

[Graham Banks]

Graham, where does the 'terminatehard=true' get added, say for Komodo 9.1?

I use ChessGUI.
When creating any new engine, there is a tick box for terminate hard. I use it for all engines.