I have started julia REPL (v.1.4.1), went into the packet manager, ran update and finally stopped julia inside the packet manager with Ctrl-D. Unfortunately not all processes were stopped. I still had a process running:
6426 ? S 0:00 /home/ad08/.julia/packages/GR/cRdXQ/src/…/deps/gr/bin/gksqt -session 10d8d4d463000158897755000000032610042_1589008042_573973
Formerly the same problem interfered with plot() with the effect that I could not plot in the REPL. Of course I can kill this process and start julia again but I think this is no good solution.
Which OS is this on? Also, cc @jheinen, since this looks like an issue with GR.
Does this persist after a restart?
@jheinen:
My OS is OpenSuse Linux 15.1. This morning I repeated the same procedure, started julia REPL, went to pkg>, update (with an error in Libtask, but this seems to be irrelevant). Then I killed in the packet manager julia with Ctrl-D.
Again I had a process still running:
2838 ? S 0:00 /home/ad08/.julia/packages/GR/cRdXQ/src/…/deps/gr/bin/gksqt -session 10d8d4d463000158902597300000062230017_1589063690_94672
I think the casual user does not know what to do and he cannot solve spurious errors. I for myself do not know how to solve this problem.
Did you make a GR plot before starting Pkg? What do you mean with: Then I killed in the packet manager julia with Ctrl-D?
Can you manually close GKS QtTerm?
Here is what I did (I had the same problem days before):
- I started my computer, then in a konsole
- julia
- ]
- update
- Ctrl-D
ps xa | grep julia
with the effect as in my original mail. I had this problem days before and now tried to repeat it. My OS has not marked subprocess 2838 as zombie. I suspect starting julia again and trying to plot has the effect that some call leads to nowhere. The konsole can only be recovered by killing julia explicitely.
How can I manually close GKS QtTerm? I don’t understand.
I have never seen this before. Do you have a startup file for Julia which (auto-)imports Plots (or GR)?
You can (manually) close the GKS QtTerm like any other Qt app via the window manager. Don’t know which window manager you have.
Does the issue also occur in normal operation?
using GR
plot(rand(5))
<Ctrl-D>
It’s really strange. I started my system in the usual way and looked for the subprocess julia (without starting julia ever before!). As before I found
2941 ? S 0:00 /home/ad08/.julia/packages/GR/cRdXQ/src/…/deps/gr/bin/gksq
…
and immediately before
2937 pts/4 Ss 0:00 /bin/bash
and I don’t know what this is doing. .bashrc is unsuspicious.
Now I think it cannot be a problem of julia, since after
julia
using GR
plot(rand(5))
Ctrl-D
I saw the plot and the subprocess 2941 has vanished. Strange!
The following gives no explanation why I have the problems with the strange subprocess.
I only noticed an error in
ldd libqt4gr.so
with the notice that libGR.so is not found. libGR3.so and libGRM.so find libGR.so
Maybe irrelevant, I don’t know. I’m still seeking for a process which may have started julia. .bashrc or .profilerc do not contain any suspicious command. Is my system hacked?
@jheinen I think I can show the problem with some simple lines: Start julia, then
using Plots
plot(rand(10)) ; savefig(“Random.pdf”)
and stop julia. Random.pdf is generated and a process
4072 pts/2 S 0:00 /home/ad08/.julia/packages/GR/cRdXQ/src/…/deps/gr/bin/gksqt
is left, which even survives a reboot.
This does not happen with:
using GR
Could you please try the following logic:
using Plots
ENV["GKSwstype"] = "100"
plot(rand(10)) ; savefig(“Random.pdf”)
There is some logic within Plots that “contacts” the output device (in your case the default GR output device gksqt) before any plot is done. I’ve never understood why.
Seems to be related to the positioning of the viewport with regard to the axes labels and other text objects …
Maybe you’ve got it. Now I have no sleeping subprocess. I only don’t know what the difference is. Is “100” arbitrary?
Should we open an issue on Plots about this? If it’s leaving an orphan process that’s a problem.
Definitely yes! I’ve just rebooted my machine and the orphan process is still there (of course with changed PID). Maybe it’s a problem of KDE too. KDE seems to store the status of my machine. I’ve not done anything else. It would be interesting to know if other have this problem on Linux too, so that we can exclude malware.
I suspect Plots calls some GR function before the first plot is shown (or saved). It might be a function to calculate the text height - I don’t know. Would be helpful if someone could debug it and point me to the corresponding code section - I could then try to fix it …
That would be easier than to “reverse engineer” it in GR …
Unfortunately, I can’t fix this problem in GR. Before Plots creates the first plot, it calculates the padding for the plot. This is done by measuring the text sizes of axis labels and annotations, which again is inquired from GR text functions (inqmathtex, inqtextext, inqtext) using the required attributes (character height, char up vector, …). All this is done in the method _update_min_padding. So this issue can only be solved, if those calculations are “postponed” to the time, when the first output is really created.
That also explains, why ENV["GKSwstype"] = "100" has to be set on headless systems, e.g. when running the tests.
Although I wrote the first version of this backend, I honestly don’t trust myself to make this change to the current backend code without side effects because the code has changed a lot.
As a consequence I have to put ENV[“GKSwstype”] = “100” in my startup.jl. This seems to work at least for me. Not important: Is there something special about the value 100?
It’s kind of a NULL output device
Would the measured padding be the same across all devices? We could then wrap that function in withenv("GKSwstype" => "100").