This is, perhaps, a quite unique setup and potentially the wrong way to do things, but worked with previous versions of SNAP 8.
SNAP installation sits in /usr/local/snap
.snap folder sits on a filesystem where all potential runtime downloads are stored (means SNAP doesn’t open HTTP connections on headless server with no internet access)
symlinks sit in users’ home dirs, e.g., /home/dmckay/.snap → /afilesystem/.snap
/usr/local/snap/etc/snap.properties and /usr/local/snap/etc/snap.conf are left as installed - i.e., the default user dir and the auxdata folders are not changed.
Previous SNAP versions (since 8.0.4) worked well with this setup, with SNAP finding pre-downloaded auxdata files (dem and S1 orbit files).
SNAP 8.0.9 fails with FileNotFound errors relating to $HOME/.snap/system/ and subfolders of that. e.g., the “lock” file, and $HOME/.snap/system/core/locale/core_snap.jar, which I think it should be getting from /usr/local/snap/snap/core/locale afaik.
My feeling is the symlink method is no longer working. However, I’ve had no success using the snap.conf and snap.properties files to configure this setup.
This is strange. In SNAP 8.0.9 nothing has changed in this direction.
Have you done a new installation/setup or only updated an existing and working installation?
You might have missed one step in your configuration?
Honestly, I don’t know why the core_snap.jar exist two time. This is related to the NetBeans configuration. Indeed, it is located at both location you mention. But this jar hasn’t changed since a while. I think since the start of SNAP 8.
This was initally an update to a working configuration - I then performed a clean install on the same machine and saw the same result. Today I will install on another machine to see if I can get a working configuration and report back.
It’s good to know nothing has changed with 8.0.9 - can you also confirm whether anything changed with 8.0.7 or 8.0.8? It’s possible the change came with a previous update but went unnoticed if updates were close together.
Going forward, I’m not against individual users having a .snap folder (~100 MB or less) as long as we can still point to pre-downloaded data during the headless runs.
The location of the core system folders and files haven’t changed since the release of SNAP 8.
For S1TBX the download locations of DEM and orbit files have changed. They are located in snap\etc\snap.auxdata.properties.
But I think this does not affect your configuration. Maybe you have changed the AuxDataPath in this file?
But still, it should work.
I’m not yet sure if SNAP is not starting at all or if just certain processing steps do not work. Could you elaborate on that?
AuxDataPath wasn’t changed and seemed happy to follow the symlink previously.
SNAP would not start at all (the desktop version hangs). The command-line versions, e.g., running snap --nosplash --nogui --modules --list, reported the FileNotFound error for files in $HOME/.snap/system. There is no system folder in the /otherfs/.snap folder the symlinks point to.
If the symlink is removed SNAP desktop and command-line versions run fine.
I now have a clean install on a separate system and I will attempt a configuration that uses snap.auxdata.properties and snap.properties. Unfortunately, having spoken to my systems team, even ~100 MB in $HOME/.snap must be avoided. Am I right in thinking that configuring snap.userdir and AuxDataPath should be enough to get this going without the requirement for a symlink in users’ home dirs?
Thanks, @marpet, I have made the changes suggested on the page you linked to in snap.conf, gpt.vmoptions and pconvert.vmoptions. It now uses /data/snap_data.
I now have:
snap.auxdata.properties:
AuxDataPath=/data/snap_auxdata
snap.conf:
default_userdir="/data/snap_data"
-J-Dsnap.userdir=/data/snap_data added to default_options
snap.properties:
snap.userdir=/data/snap_data
The result is that running snap still creates a ~/.snap folder, but this is now 68 KB. If snap.conf is unchanged, but all of the other files are changed as above, a ~/.snap folder is created, but is 45 MB.
I think this configuration is acceptable now.
Do you forsee any issues with this configuration not being user-specific? I considered default_userdir="/data/snap_data/$USER", which works for snap, but $USER is not interpreted when using vmoptions, so gpt and pconvert wouldn’t work so nicely.
Note: I’ve changed the title of this thread as the problem was not caused by the update to 8.0.9 as I first thought.
Hi,
Thanks to this new configuration I’ve managed to get closer to the root of the problem.
This configuration works fine on my test system, where “/data” is just a folder on the same filesystem.
However, attempting to setup the same configuration on the production system results in SNAP (desktop or command line) hanging. In this case, “/data” is an NFS-mounted external drive.
If I reconfigure SNAP to use a local folder (through the files in the snap etc folder, as above), it runs.
So the issue seems to be with SNAP reading/writing to the NFS filesystem.
In general, this should work. I just did this too and changed the paths to our network storage. For me it worked. On the server we use samba. My system is running Windows.
I’ve searched for issues of Java with NFS, but haven’t found something.
Thanks for that info, and very good point on bringing my IT in.
I’ve done two things this morning:
I’ve come up with a “hybrid” approach where the snap.userdir settings point to a folder on the /home filesystem - this will be a shared folder amongst the users and seems to be sitting at ~150 MB. The fact there aren’t multiple copies in $HOME/.snap should be ok - hopefully we can handle 1x150 MB rather than nx150 MB with n users! The “hybrid” part is I’m hoping AuxDataPath=/data/snap_auxdata (i.e., having Orbits and dem folders on our NFS drive) will work. We (myself and a colleague) are testing that now.
I’ve emailed our systems support for any ideas on why the NFS-mounted system is causing the software to hang, while the /home filesystem does not. Noting that other operations on that network drive are not slow.