M2
M2 copied to clipboard
Macaulay2
Write access on cache/*.db files required
When I install the current master branch on our shared file system, regular users can not run M2 without write access to the lib/cache/ directories. None of the .db files are modified during the run, but M2 fails without admin privileges to do so. I confirm this by removing my privileges and running M2. The current work-around is to run M2 with "--no-debug", but it still produces a number of warning messages.
We're running RHEL 7.5 with AFS as our shared filesystem. This was not a problem in version 1.8, which is why I wondered if it might be a bug. `% M2 Macaulay2, version 1.12.0.1 ../../../x86_64_linux/m/macaulay2/1.12/share/Macaulay2/Core/packages.m2:262:25:(1):[20]: error: Can't be reader : /afs/crc.nd.edu/x86_64_linux/m/macaulay2/1.12/lib/Macaulay2/Elimination/cache/rawdocumentation-dcba-8.db ../../../x86_64_linux/m/macaulay2/1.12/share/Macaulay2/Core/packages.m2:262:25:(1):[20]: --entering debugger (type help to see debugger commands) ../../../x86_64_linux/m/macaulay2/1.12/share/Macaulay2/Core/packages.m2:262:25-262:38: --source code: rawdb := openDatabase rawdbname;
i1 :`
Our 3rd party database library is "gdbm", and it tries to "lock" the database files that it opens, so they don't get changed while in use. There are various ways to lock a file in unix (flock, lockf, and fcntl), and some of them are not implemented by shared file systems. Gdbm tries to use all of them, but maybe it screws up, or maybe its configure script doesn't do a good job of detecting which ones you have available. The relevant locking routine is _gdbm_lock_file in the file gdbm-1.9.1/src/lock.c.
If you are building M2 yourself from source code, I recommend giving configure the option --enable-build-libraries=gdbm so it will build gdbm from source code, rather than using the version on your system. Perhaps that will make a difference.
PS: I also recommend building from the 1.12 release branch, rather than from the development branch.
