Graphviz, dot and snap

snapcraft
1

Hi –

Probably a long shot, but I’ve been working on a snap for a documentation system. One of the dependencies is plantuml, which itself depends on graphviz and dot. The snap almost works, except that about 1/2 of the time I use snap run to build a large-ish doc project, I get stack dump from somewhere within plantuml/graphviz about a file stream timeout, which I never get outside of the snap. It builds successfully about 50% of the time as I said, but that’s not good enough. Anyone have any similar issues with java file IO and snaps?

Spence

3

I figured out when it happens but not why. PlantUML (a diagramming java tool) is run with a wrapper script that respects the JAVA_HOME environment variable.

If I install openjdk as a staged package within the snap and set the JAVA_HOME environment variable to point to openjdk within the snap, plantuml fails about 50% (87 out of 200 runs) with an error like:

WARNING: failed to run plantuml: java.io.IOException: Stream closed
  at java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:433)
  at java.io.OutputStream.write(OutputStream.java:116)
  at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
  at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
  at java.io.FilterOutputStream.close(FilterOutputStream.java:158)
  at  net.sourceforge.plantuml.cucadiagram.dot.ProcessRunner$MainThread.startThreads(ProcessRunner.java:185)
  at net.sourceforge.plantuml.cucadiagram.dot.ProcessRunner$MainThread.runJob(ProcessRunner.java:123)

(The stream it is trying to write to is an image file somewhere in the user’s home directory.)

If I remove openjdk as a staged package and instead let PlantUML find the JAVA_HOME in my normal, non-snap environment, it never fails. In other words, in this scenario, PlantUML uses the same version of java, just a version installed outside the snap and works fine.

I have used openjdk in other Java game snaps w/o issue.

Any ideas?

4

Is this classic confined? If not, then there is little chance of finding java outside of the snap.

5

Yes, this is confusing because I was making assumptions that aren’t true. In my normal environment, I have JAVA_HOME set. When I run a wrapper script inside a snap, it finds that JAVA_HOME and tries to run java based on that path, which of course doesn’t exist inside the snap, so I have to set JAVA_HOME inside snapcraft.yaml to override this.

My best guess as to what is happening based on somewhat painful debugging is that 2 versions of java are being installed inside the snap. One is explicit and the other is pulled in as an indirect dependency. Trying to narrow down exactly what is being called and when. My guess is that there is some sort of cross pollination thing going on between java installs.

6

If you are not, I suggest setting the base keyword to either core or core18. You can then pick the openjdk jdk and jre version corresponding to Ubuntu 16.04 or Ubuntu 18.04 that you want (two versions are available on each).

Are you using more than one part? If both are using one of the java based plugins, ensure they have similar part properties.

Lastly, make sure you are using snapcraft from https://snapcraft.io/snapcraft

7

Thanks. I am using core18. I have now verified that the same version of the JVM is being used with each part. The error is a bit mysterious. Seems like something in PlantUML is running a system process with a default small timeout, so I may try digging around in PlantUML source to figure it out.