plantuml / plantuml-server

PlantUML Online Server
https://plantuml.com/
GNU General Public License v3.0
1.67k stars 477 forks source link

Cannot find Graphviz #313

Open ronaldd2 opened 1 year ago

ronaldd2 commented 1 year ago

Describe the bug When rendering a C4 model an error is shown Dot executable does not exist. Cannot find Graphviz

The expected location is /usr/bin/dot but the actual location is /usr/local/bin/dot

Expected behavior Correct rendering without error

Screenshots Screenshot 2023-09-21 094456

Server

Work around Made a hard link in the local docker image so dot can be found in /user/bin/

HeinrichAD commented 1 year ago

Hi @ronaldd2,

Could you please provide an example what (and how) you try to render and result in the error?

I tried to test the latest jetty version but can not reproduce any error.

docker run -d --pull always -p 8080:8080 --name plantuml plantuml/plantuml-server:jetty
docker logs -f plantuml

$\rightarrow$ http://localhost:8080


ronaldd2 commented 1 year ago

@HeinrichAD This is weird, when I enter your simple command on the website of our server it renders correctly. However when I'm using Visual studio code with the Plantuml plugin from jebbs I get the error again. Inside the plugin I configured to use our own server and the problem solves when I make a link to dot on our server. The testdot doesn't work at all in VSC

HeinrichAD commented 1 year ago

@ronaldd2 again, I tried the vscode extension jebbs.plantuml and got no problems. I could also render the version and testdot diagram.

Could you please check the following extension settings:

  1. plantuml.server has the correct URL to your own plantuml server (e.g. http://localhost:8080)
  2. plantuml.render is set to PlantUMLServer (to ensure that not the local plantuml instance but the server is used)

You can also check if the server really is rendering the diagram. To do that, just look into the plantuml log

# note that `-f` is important here
docker logs -f <docker-conainer-id-or-name>

and see if rendering the following code snippet shows [Log] Hello World:

@startuml
!log Hello World
@enduml

If [Log] Hello World does not appear inside the terminal/docker log, you know that you are not using the plantuml server, but most likely rendering your diagram locally. In this case check your extension settings again.

ronaldd2 commented 1 year ago

@HeinrichAD I double checked it already and when making the hardlink in the docker image the problem is solved. So i'm not running it locally. This is what I see in the docker log without the hardlink:

java.io.IOException: Cannot run program "/usr/bin/dot": error=2, No such file or directory
    at java.base/java.lang.ProcessBuilder.start(Unknown Source)
    at java.base/java.lang.ProcessBuilder.start(Unknown Source)
    at java.base/java.lang.Runtime.exec(Unknown Source)
    at net.sourceforge.plantuml.dot.ProcessRunner$MainThread.startThreads(ProcessRunner.java:165)
        ...
HeinrichAD commented 1 year ago

@arnaudroques Since you changed the dot file location code and some other Graphviz stuff not too long ago. (E.g. here: https://github.com/plantuml/plantuml/commit/63a09e2#diff-db4f5f51af6438174c994a13261270758f10c643252eb1ab56840332184f0aee) Do you have an idea why /usr/bin/dot instead of /usr/local/bin/dot is tried to use?

I mean the simplest solution is like @ronaldd2 already stated in the original issue text to create a hard link. But maybe we could try to find the root of this problem since this solution is only valid for the PlantUML Server. (To be more specific only for the docker versions of PlantUML Server.)

vamsi-juvvi commented 1 month ago

Since this post is more than a year after the last comment, It is likely any dot path issues have been fixed. However, my problem presents the same way except there is no entry in the docker log at all. Strange coincidence. I have listed the fix here (Nothing to do with PlantUML server. Peculiarities with VSCode settings and Jebb's PlantUML Extension).

Root cause of my problem

The root cause is that the PlantUML Extension (by Jebbs) defaults to local server when plantuml.server is not set. The extension ships with plantuml.jar and uses a locally installed java but expects the user to install graphwiz/dot on linux/mac. The error is likely from that local instance not finding dot. The error message with unix paths can be confusing (Since I am on windows, I assumed it was from the linux docker container). However, when doing remote development, the plantuml extension is installed on the remote host (linux) and uses the environment on that linux host: hence the unix paths in the error msg. Java was installed by default on my Ubuntu server and the only thing missing was graphviz.

The proximal cause of this (in my case atleast) is that the workspace settings had a {plantuml.server: ""} instead of {}. This made VSCode/Extension think I wanted local. I thought by clearing out the field in the settings UI, it would disappear, but it was set to "" instead. Thereforce, did not fall-through to the "Remote" settings.

Once I emptied out the workspace settings to {} via manual edit of the Workspace settings (JSON) the extension switched to the "Remote" settings and everything worked.

Investigation

image

I have had the exact same issue when I decided to switch to a locally hosted (on a different server but same LAN) plantuml. What was mystifying was that a VSCode instance on another workspace hit the local server while the other instance on another workspace bombed with the usr/bin/dot error.

My windows VSCode was managing code on a linux server using Remote-SSH. Since the plantuml container was running on the same server, I set the PlantUML Server to http://localhost:8181 under Remote [SSH: Beast]. This then resulted in the missing dot error with nothing in the container logs. Thinking some issues in the settings, I opened up the JSON settings files in order (User, Remote and Worpspace). Turns out that on the offending VSCode instance, the workspace settings had the following.

{
    "plantuml.server": ""   
}

Simply clearing that out to {} took care of the problem.