Patch to kill processes cleanly

[GoogleCodeExporter]

What steps will reproduce the problem?
1. invoke mencoder with libavcodec (lavcopts) threads > 1 on Linux or an
mencoder wrapper on any platform
2. destroy the process e.g. stop playing
3. check Windows Task Manager/ps

What is the expected output? What do you see instead?

Expect: no orphan processes. Get: orphan processes.

What version of the product are you using? On what operating system?

Subversion HEAD (revision 396). Windows XP Pro SP3 and Ubuntu 9.10.

If you are transcoding a media file, which engine are you using (mencoder,
avisynth/mencoder, tsmuxer?)

Tested with mencoder and pmsencoder, but the same issues would arise with
any wrapper and any transcoder that launches multiple processes.

If the media file is in error (or does not play flawlessly), what are the
codec informations of this file (you can use following program:
mediainfo.sourceforge.net) ? 

Please provide any additional information below and PLEASE JOIN debug.log
file !!

PMS kills processes in a way that leaves behind orphan processes. This is a
long-standing bug in java.lang.Process that PMS ports to Unix :-) i.e. on
Windows, Process.destroy calls TerminateProcess(), the only way to kill a
process, but doesn't destroy any child processes created by that process.
On *nixes, PMS does this the safe way initially, by calling
Process.destroy(), which sends a TERM signal to the process. But it then
duplicates the unsafe Windows behaviour by sending a SIGKILL to the
process. There's lots of literature on why issuing a kill -9 is unsafe, as
it doesn't give a process a chance to clean up i.e. it should only be done
in exceptional circumstances. Likewise, the Microsoft literature warns
against TerminateProcess(), even though that's the only process shutdown
mechanism it supports! (It provides an improved mechanism for terminating
"jobs" on Win2K+, but that doesn't apply here.)

This issue was detected via PMSEncoder, which launches an mencoder
subprocess. It can trap the TERM signal and clean up the mencoder
child/children, but the SIGKILL that immediately follows often (usually, in
my tests) prevents it getting a chance. The result is the creation of
mencoder orphans. Seeking on a file that's being transcoded by mencoder
results in multiple invocations of mencoder with different seek offsets,
and the unclean shutdown can easily result in the creation of a large
number of orphan processes.

The attached patch solves this problem on Windows by using winp. winp is an
open source Java library that supports the termination of a process *and
all its children* on 64- and 32-bit Windows. It has been battle-tested and
widely used in the Hudson continuous integration server.

The non-Windows (i.e. Unix) fix is simply to remove the evil kill -9 hack :-)

Original issue reported on code.google.com by chocol...@cpan.org on 16 Feb 2010 at 12:23

Attachments:

• ProcessUtil.patch

[GoogleCodeExporter]

More info:

A Perl script that simulates the current process termination behaviour and 
creates
orphan processes:

http://github.com/chocolateboy/pmsencoder/blob/master/dev/mencoder_orphanizer.pl

winp article:

http://weblogs.java.net/blog/2008/03/16/introducing-winp-windows-process-manipul
ation-library

Why *not* to use kill -9:

http://sial.org/howto/shell/kill-9/

Forum report of "zombie" processes:

http://ps3mediaserver.org/forum/viewtopic.php?f=7&t=3094&start=0

Microsoft warn against TerminateProcess() (ExitProcess() is not a solution as it
terminates the *current* process):

The TerminateProcess function is used to unconditionally cause a process to 
exit. The
state of global data maintained by dynamic-link libraries (DLLs) may be 
compromised
if TerminateProcess is used rather than ExitProcess.

Original comment by chocol...@cpan.org on 16 Feb 2010 at 12:34

[GoogleCodeExporter]

Yeah, the kill -9 is a hack that was implemented because there were processes 
that
kept running due to a bug I think. I'm not sure if it's needed anymore.

I'll check if everything still works as expected when removing it.

Shagrath will need to take a look at the Windows part.

Original comment by robinmul...@gmail.com on 23 Mar 2010 at 10:13

• Changed state: Accepted

[GoogleCodeExporter]

Just to be sure, have you tested this on Linux/OS X or just the Windows part?

Original comment by robinmul...@gmail.com on 23 Mar 2010 at 10:16

[GoogleCodeExporter]

I've tested it on Windows XP Pro SP3 and Ubuntu 9.10.

Original comment by chocol...@cpan.org on 23 Mar 2010 at 7:12

[GoogleCodeExporter]

Original comment by shagr...@gmail.com on 29 Sep 2010 at 10:23

• Changed state: Started

[GoogleCodeExporter]

winp downloads: http://maven.dyndns.org/2/org/jvnet/winp/winp/

Original comment by chocol...@cpan.org on 8 Oct 2010 at 8:48

[GoogleCodeExporter]

The patch was tested against winp 1.14, which is still the latest version. The 
only reference to the version is the Eclipse .classpath entry, which should be 
adjusted accordingly if a new version is released/used.

Original comment by chocol...@cpan.org on 8 Oct 2010 at 9:14

[GoogleCodeExporter]

Patch updated (against r412) to remove the Windows fix as per the discussion 
starting here:

http://ps3mediaserver.org/forum/viewtopic.php?f=14&t=7844&start=130#p38719

Original comment by chocol...@cpan.org on 1 Nov 2010 at 12:59

Attachments:

• issue_680_no_winp.patch

[GoogleCodeExporter]

Issue 778 has been merged into this issue.

Original comment by chocol...@cpan.org on 13 Jan 2011 at 7:57

[GoogleCodeExporter]

Fixed in r422.

Original comment by chocol...@cpan.org on 15 Jan 2011 at 4:43

• Changed state: Fixed

[GoogleCodeExporter]

OS: Ubuntu 8.04
PS3MediaServer version: r472

It looks like the problem has not been solved yet. The mencoder process got 
killed correctly when end of the movies is reached, however when I stop the 
movie somewhere in the movie the mencoder process is still active while in the 
debug file states that the process including the child process have been killed.
This problem occurs on any files I watch (mkv, mpg, vob, avi etc.).
I don't have this problem with r412 release.

Original comment by buu.tam...@gmail.com on 4 Feb 2011 at 3:08

[GoogleCodeExporter]

Original comment by chocol...@cpan.org on 4 Feb 2011 at 3:12

• Changed state: New

[GoogleCodeExporter]

Tried to use windows taskkill to forcefully close all children processes and it 
seems to work OK. WINP is quite buggy when talking about child processes(core 
win processes were killed) so I patched it this way(quite dirty patch):
http://code.google.com/p/pms-exsport/updates/list
Check r8/r10

Original comment by ExSportCZ@gmail.com on 5 Feb 2011 at 10:28

[GoogleCodeExporter]

> It looks like the problem has not been solved yet.

Thanks for the report. This should be improved (for Linux/Unix) in r484.

Original comment by chocol...@cpan.org on 7 Feb 2011 at 2:30

[GoogleCodeExporter]

Original comment by chocol...@cpan.org on 8 Feb 2011 at 9:56

• Changed state: Started

[GoogleCodeExporter]

The problem has been fixed with r484 and higher. Thanks for the quick fix.

Original comment by buu.tam...@gmail.com on 9 Feb 2011 at 8:54

[GoogleCodeExporter]

On Windows, there's also this:

http://technet.microsoft.com/en-us/sysinternals/bb896683

Original comment by chocol...@cpan.org on 21 Feb 2011 at 11:58

[GoogleCodeExporter]

For Windows you can use built-in taskkill so you don't need to pack this tool 
with PMS.
I used it already in my custom build(totally dirty):
http://code.google.com/p/pms-exsport/updates/list
Check r8/r10

Original comment by ExSportCZ@gmail.com on 22 Feb 2011 at 8:30

[GoogleCodeExporter]

Issue 1264 has been merged into this issue.

Original comment by chocol...@cpan.org on 5 Nov 2011 at 11:15