Precompilation lock file not released when process exits

[timholy]

julia> using CodeTracking
Precompiling CodeTracking
  Progress [>                                        ]  0/1
  ◓ CodeTracking Being precompiled by another process (pid: 19746)

but

tim@flash:~$ kill -9 19746
-bash: kill: (19746) - No such process

[vchuravy]

What OS is this on? cc: @IanButterworth

[IanButterworth]

@vtjnash the message indicates the hostname matches so it seems the live process check isn’t working?

[vtjnash]

Live process isn't a criteria though

[IanButterworth]

Isn’t Pidfile.isvalidpid polled while waiting on the lock and that function checks for the pid being live?

[timholy]

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).

[maleadt]

Live process isn't a criteria though

julia/stdlib/FileWatching/src/pidfile.jl

Lines 181 to 183 in 3c64bc3

	# see if the process id exists by querying kill without sending a signal
	# and checking if it returned ESRCH (no such process)
	return ccall(:uv_kill, Cint, (Cuint, Cint), pid, 0) != UV_ESRCH

(what @IanButterworth mentioned)

[davidanthoff]

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]

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]

Which 1.10?