Closed timholy closed 10 months ago
What OS is this on? cc: @IanButterworth
@vtjnash the message indicates the hostname matches so it seems the live process check isn’t working?
Live process isn't a criteria though
Isn’t Pidfile.isvalidpid
polled while waiting on the lock and that function checks for the pid being live?
What OS is this on?
julia>
tim@flash:~/$ uname -a
Linux flash 4.15.0-206-generic #217-Ubuntu SMP Fri Feb 3 19:10:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
This is running directly on the host (no VM).
Live process isn't a criteria though
(what @IanButterworth mentioned)
Just a +1, this is a big problem, IMO. One can very easily end up in this scenario, over the last couple of days I've hit this all the time: for example, on Windows, simply closing the terminal window by clicking on the red X in the top right corner will cause this, and then one has to wait six minutes until Julia will try to precompile that package again. I think this issue should be a release blocker for the 1.10 release.
There are many other scenarios where this can be triggered. For example, the VS Code extension will kill Julia processes in many situations in entirely "normal" user scenarios, and then each time a user can end up in this state where things won't work for six minutes.
I don't fully understand how the pid locking here is implemented, but at least for Juliaup I'm simply taking locks on the pid file, and they very reliably get released when the locking process is terminated. So there is never a situation where a process might wait for a process that no longer exists, and that implementation requires no polling, and as far as I can tell is a pretty standard pattern of solving this kind of problem. Seems to me that something along those lines would be helpful here too? Or maybe there is some other solution, primarily I just think the current implementation needs to be fixed.
I seem to have gotten myself into this infinite loop while trying out 1.10 (on VSCode, Mac M2). I'm not very knowledgeable when it comes to lockfiles etc. Is there a way to get myself out of this at the command line? Killing the process doesn't seem to work...
Which 1.10?
The issue started on 1.10.2, then I updated to 1.10.3 (where at least it refreshes the message now every few seconds, but still hangs):
By 1.10.2 I assume you mean 1.10.0-beta2 etc.
Are you able to share an environment that reproduces this?
Exactly. By environment you mean Project.toml and Manifest.toml?
Which version was that manifest resolved with? It's in the old format so you should also consider upgrading it so that it records the julia version
Pkg.upgrade_manifest()
Hi I found something similar for Julia v1.10-beta 3 when using it on HPC. I was trying to run julia program on a HPC, and its login node will kill the precompiling process. So I allocate some resource using the command srun -p NAME -n 4 --pty julia, but when precompiling the output shows something like
(@v1.10) pkg> add ExTinyMD
Updating registry at `~/.julia/registries/General.toml`
Resolving package versions...
No Changes to `~/.julia/environments/v1.10/Project.toml`
No Changes to `~/.julia/environments/v1.10/Manifest.toml`
Precompiling project...
Progress [> ] 0/51
◑ Compat Being precompiled by another machine (hostname: login1.*.*.*, pid: 855648)
which shows the precompiling process is still running on the login node and the process got killed. Then I tried 1.9, this problem did not happen and the process was success.
Just hit this on a fresh install after killing precompilation with Ctrl-C on 1.10.0-beta3
The failed builds never recover afterwards either, its all ✗permanently this was an unrelated issue
Is this fixed by #51714?
Yes, also Pkg changes from https://github.com/JuliaLang/Pkg.jl/pull/3654 in https://github.com/JuliaLang/julia/pull/51732
but