vchuravy
commented
1 year ago What OS is this on? cc: @IanButterworth
Closed timholy closed 10 months ago
vchuravy
commented
1 year ago What OS is this on? cc: @IanButterworth
IanButterworth
commented
1 year ago @vtjnash the message indicates the hostname matches so it seems the live process check isn’t working?
vtjnash
commented
1 year ago Live process isn't a criteria though
IanButterworth
commented
1 year ago Isn’t Pidfile.isvalidpid polled while waiting on the lock and that function checks for the pid being live?
timholy
commented
1 year ago 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/LinuxThis is running directly on the host (no VM).
maleadt
commented
1 year ago Live process isn't a criteria though
(what @IanButterworth mentioned)
davidanthoff
commented
12 months ago 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.
maxasauruswall
commented
10 months ago 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...
IanButterworth
commented
10 months ago Which 1.10?
maxasauruswall
commented
10 months ago 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):
IanButterworth
commented
10 months ago By 1.10.2 I assume you mean 1.10.0-beta2 etc.
Are you able to share an environment that reproduces this?
maxasauruswall
commented
10 months ago Exactly. By environment you mean Project.toml and Manifest.toml?
maxasauruswall
commented
10 months ago IanButterworth
commented
10 months ago 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()
ArrogantGao
commented
10 months ago 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.
rafaqz
commented
10 months ago 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
JeffBezanson
commented
10 months ago Is this fixed by #51714?
IanButterworth
commented
10 months ago Yes, also Pkg changes from https://github.com/JuliaLang/Pkg.jl/pull/3654 in https://github.com/JuliaLang/julia/pull/51732
but