VSCode sysimage build hangs on my NFS home directory

I’m not really sure this is a bug with VSCode or Julia, so I’ll just throw it out there for discussion and file a bug if something comes of it.

I tried building a sysimage for a project I’m working on this morning. Doing so causes vscode to build the sysimage, produce a file, even write that it had completed, and then hang. It winds up in my kernel log that vscode has been hung for a really long time (hundreds of seconds)… At this point I have to reboot my device and then delete the sysimage in order to make anything work.

Now, I’m running an NFS mounted home directory, and it’s served by a cluster of 2 RPi4s running glusterfs, with NFSganesha as the NFS server and using NFSv4 with kerberos authentication. So it’s not a common situation, but it’s similar enough to what you might find on a high performance computing cluster that this should probably be considered as not way out there for Julia users.

In general, I find that it’s not just vscode but every so often I can trigger this kind of behavior in some program, like maybe reading in a CSV file and writing out some massive filtered version… or other heavy filesystem operations often on large files. One thing is that my desktop machine has power saving, so it will go to sleep (though it didn’t go to sleep during the build). In general I just put up with this crap for now. However I’m wondering if anyone else is able to trigger a similar thing using an NFS home directory, and/or is there perhaps something specific that vscode could do differently or not do which would prevent it triggering this?

See Save yourself some headache and don't put JULIA_DEPOT_PATH on your NFS home directory

Haha! I wrote that thread!

But I don’t have the depot path on my home directory, in this case it’s the project directory which is on my NFS home directory… and yeah, I can’t see changing where I put my work projects, since that’s the point of the NFS home in the first place.