Crash if TEXMFVAR is not writable

[hmenke]

If neither TEXMFSYSVAR nor TEXMFVAR are writable and luaotfload is loaded, LuaTeX just crashes without an error code or anything. The situation that TEXMFSYSVAR is not writable is very common, however, TEXMFVAR not being writable is much less common, but can happen if you are running in a restricted sandboxed environment, like a CI service or so.

MWE

\input luaotfload.sty
Hello world!
\bye

Make sure that neither TEXMFSYSVAR nor TEXMFVAR are writable and try to compile:

$ luatex test.tex
This is LuaTeX, Version 1.12.0 (TeX Live 2020) 
 restricted system commands enabled.
(./test.tex (/usr/local/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload.sty
(/usr/local/texlive/texmf-dist/tex/latex/base/ltluatex.tex)
$

[zauguin]

The actual restriction is that TEXMFCACHE has to contain something writable. (This defaults toTEXMFVAR and TEXMFSYSVAR though, so effectively you get the observed behavior.)

The issue can be separated into two parts: luaotfload doesn't work with non-writable TEXMFCACHE and luaotfload just quits without any apparent error.

The first one is more or less by design. Both TEXMFCACHE and TEXMFVAR are clearly decumented as directories for storing cached personal runtime data, no having them not writable is broken configuration. (That also leads to issues in other engines if runtime data needs to be stored)

Of course, we should add proper error reporting here. It's a bit complicated because the upstream code is taking a rather extreme approach is error handling here, but we can patch some functions to get it in line.

[hmenke]

I object strongly. The key difference to other engines/packages is that write access to the cache is required at runtime. Most of the stuff that requires write access to the cache, like updmap or fmtutil can be run ahead of time (and usually is, as part of tlmgr update). That said, automatic font generation also fails when the cache is not writable, even if an absolute path is specified for the output directory. I have reported a bug for this in TeX Live: https://tug.org/pipermail/tex-live/2020-August/046013.html

[u-fischer]

Hm also with pdftex you need a writable texmfvar if tfm or pk has to be created. Ah I just saw that this what you are complaining about. But can't you redirect texmfvar in this case?

[zauguin]

In dev there is a version with better error handling now. About running without a writable cache, I'm with Norbert: Pretty much every setup should be able to provide some writable cache, in my experience even CI services/containers/... have some temporary storage location you can set TEXMFCACHE to. Since pretty much every document will require more than one run, this will also lead to better performance than skipping any caching.

Additionally there isn't that much we can do here anyway, the code for caching which exits is in fontloader-basics-gen which is also a part of the reference fontloader. So if we don't start patching the fontloader, we are pretty much stuck with the current handling.