Debugging this type of LaTeX issue is usually extremely hard, so the first thing I’d try is reinstalling texlive from scratch (rm -rf /opt/texlive/ and /tmp/install-tl-* too if it still exists, then re-run the commands from our texlive install guide) to make sure it’s fully up to date.
Also, when did you install texlive? They have rolling releases so it’s impossible for us to recreate the same environment you have, but knowing if a recent change broke something would already help.
In case you are on CentOS or any other system with SELinux enabled also check if this is causing any problems (try setting it to permissive temporarily).
PS: The timetable PDFs do not use LaTeX - that’s why they work even if nothing latex-related is enabled at all.
Initially I had installed texlive 20200803. I removed it, and installed from scratch texlive 20200916. I also set SELinux to permissive, and upgraded Indico from version 2.2.8 to version 2.3. The error persisted between and after all these changes.
OS is CentOS 7.8.
Because it seemed weird that xelatex succeeded when run manually, I made a wrapper for xelatex, that prints to a file the parameters and environment and then calls xelatex. I found that when xelatex is called by Indico, this additional environment parameter is set:
Hello, I have exactly the same issue… week old installation, CentOS7.8, Indico 2.2.8, texlive 20200913. The same error. My dirty workaround was not to populate TEXMFCNF env variable by modify line 137 of file
I think your workaround simply prevents the custom config file from being used, and thus removes a last line of defense against malicious LaTeX code trying to read local files (like a config file containing a password) that managed to get through our LaTeX sanitization.
Not sure how to solve it so far… let’s see if people more familiar with LaTeX have an idea… or maybe it’s a bug in texlive…