8

I have a java jar command, and I'm calling it from inside python using Popen. I'm happy that I'm doing it right, and theres lots of reasons why I'm doing it this way (its not great, but it is what it is).

When I run the Java locally, it works fine (JRE 1.8), when I run the python locally that calls the Java, it works fine. When I run it inside a docker container, it just hangs - the python on the process.communicate() and when i do a docker exec, it just does not return (the output from the command is exactly as I expect).

What I've discovered that unless theres an explicit System.exit(0); at the end of the Java, then the Java process does not end when run inside of a docker container - it just hangs, at the point of all processing being done.

To check this, I made a Hello World app consisting of 5 lines (the System.exit i comment out or in to check that this works or doesn't)

public class Hello {
    public static void main(String[] args) {
        System.out.println("Heellllooo");
        // System.exit(0);
    }
}

I bundled this into a Jar and put it in the folder where the 'real' jar sits, and execute.

Without the system.exit() the process hangs. With it it exits cleanly. In both instances, 'Heelllloooo' is printed.

Other random facts that might help diagnosis the command i'm using to check is this: (the popen in python is much more complex with the arguments I'm passing into Java).

docker exec [tag] java -jar libs/Hello.jar

If I do:

docker exec [tag] java -version

it returns immediately with the version info.

I'm running a Mac, so this is running inside of a docker-machine boot2docker Ubuntu vm thing. Other people running the same docker-images on Debian and Ubuntu machines do not have any problems with this at all.

I don't believe the problem is anything to do with Python because the symptoms are there when running it from the exec (hence me not tagging it python).

My question: Why doesn't the java process exit when the main function returns?

To be clear, I don't want to know how to kill the process (I know how to do that), what I want to know is why the process does not return. (and this seems to be a specific java / docker thing).

Jmons
  • 1,766
  • 17
  • 28
  • Please check [Link1](https://groups.google.com/forum/#!topic/docker-user/PVdrtb7-3Oo), [Link2](http://stackoverflow.com/questions/22413563/docker-container-refuses-to-get-killed-after-run-command-turns-into-a-zombie) – a3.14_Infinity Dec 14 '15 at 12:06
  • Also: http://stackoverflow.com/a/33119321/6309 – VonC Dec 14 '15 at 12:13
  • @a3.14_Infinity I think those problems are related to the -i interactive, which I am not using. If you use -i and don't close the input stream it seems to hang (which makes a lot of sense, even if its a bit frustrating) - I'm not touching system.in. -t does nothing for me (and would not help when running in the popen() subfunction either (i think)). Link 2 is about zombies - this process is not a zombie, it just hasn't returned. – Jmons Dec 14 '15 at 12:18
  • @VonC that link whilst interesting, i cant see how it relates: when i run docker exec, i am not issuing a sigterm or sigkill command. All other commands (like exec ls or exec uname -a, or even exec java -version) work fine and return. Was there something specific you meant there? – Jmons Dec 14 '15 at 12:20
  • 1
    @JamesTaylor it was just in case it was a zombie process, but you mentioned it wasn't. So it does not apply to your question then (which is why I only mentioned it as a comment, not an answer) – VonC Dec 14 '15 at 12:27

1 Answers1

2

Unfortunately, this looks like a case of https://github.com/docker/docker/issues/18180, which is still (at least as of 2015-12-18) unresolved (besides downgrading the kernel or modifying the application code).

tianon
  • 1,866
  • 3
  • 22
  • 37
  • Thanks! it does seem to be related. (sorry to not reply sooner - Christmas etc). I will monitor that bug waiting for a patch thats deployed (it looks like there is now a patch and it is only time to get it out into deployed bits. – Jmons Jan 06 '16 at 14:36
  • I'm going to (finally) mark this as accepted, as using docker that includes that bugfix seems to work. – Jmons Aug 08 '16 at 13:35