Installation

pdfTeX error

pdfTeX error

by Arnold Pizer -
Number of replies: 24

Hi,

On a new installation of WW2.18 following the instructions in Installation Manual for 2.18 on Ubuntu, I get the following error (in the hardcopy.log) trying to generate a pdf of the Orientation (or any other) set:

!pdfTeX error: /usr/bin/pdflatex (file tcss0900): Font tcss0900 at 600 not found

 ==> Fatal error occurred, no output PDF file produced!

check_modules.pl and check_latex both run without flagging any errors.

Any ideas?


In reply to Arnold Pizer

Re: pdfTeX error

by Glenn Rice -

On Ubuntu that font should be included in the texlive-base package.  If you have the texlive package installed, then that package should also be installed as it is a dependency of the texlive package (indirectly via the texlive-latex-base package).

In reply to Glenn Rice

Re: pdfTeX error

by Arnold Pizer -

Tried reinstalling.  Get the message:

texlive is already the newest version (2021.20220204-1).

texlive-latex-extra is already the newest version (2021.20220204-1).

texlive-science is already the newest version (2021.20220204-1).

This is on Ubuntu 22.04.2 with upgrades.  

On the system I find:

./texlive/texmf-dist/fonts/tfm/jknappen/ec/tcss0900.tfm

so it looks like the font is installed.

Other things to look at?  


In reply to Arnold Pizer

Re: pdfTeX error

by Glenn Rice -

Try running "sudo apt install --reinstall texlive-base" to see if something went wrong with the installation.

Also check that you have the texlive-science package installed.  That is a new package that is required for 2.18.

In reply to Glenn Rice

Re: pdfTeX error

by Arnold Pizer -
Did that and tried a hard copy of a second assignment. Got exactly the same error (same font missing). Then tried
sudo apt install --reinstall texlive-base texlive-latex-extra texlive-science
and tried a hard copy of a third assignment. Again got exactly the same error (same font missing).

Maybe I'll try using pdflatex independent of WeBWorK. Any other debugging ideas welcomed.
In reply to Arnold Pizer

Re: pdfTeX error

by Arnold Pizer -

Hi again,

Running "tex --version" gives:

TeX 3.141592653 (TeX Live 2022/dev/Debian)

kpathsea version 6.3.4/dev

Glenn (or others), is this the version you are running without problems? I am trying to determine if this is a problem with my particular installation or something more general.

Thanks,

Arnie


In reply to Arnold Pizer

Re: pdfTeX error

by Glenn Rice -
I am seeing the same version on my system, and have not issues. All of the information you have posted is the same for my system. Ubuntu is 22.04.2. The texlive versions are all the same. I am not sure what to tell you to try.
In reply to Glenn Rice

Re: pdfTeX error

by Arnold Pizer -

The has something to do with my WeBWorK setup.  If I run pdflatex from the command line on the .tex file WeBWorK produces, everything works fine.

In reply to Arnold Pizer

Re: pdfTeX error

by Glenn Rice -

Check your config files.  Try diffing the files to the dist files to see what is different.  In particular, check the $externalPrograms{pdflatex} variable in site.conf.  There are quite a few other variables used for hardcopy generation, so it may be something else instead.

In reply to Glenn Rice

Re: pdfTeX error

by Arnold Pizer -
I will check that but here is a bit more info. If I run pdflatex from the command line as root it creates the files:
root@wwserver:~/.texlive2021/texmf-var/fonts/pk/ljfour/jknappen/ec# ll
total 20
drwx-----T 2 root root 4096 Aug 4 15:52 ./
drwx-----T 3 root root 4096 Aug 4 15:52 ../
-rw------- 1 root root 9524 Aug 4 15:52 tcss0900.600pk

However, from the directories saved by WeBWorK I see:
root@wwserver:/opt/webwork/webwork2/tmp/myTestCourse/hardcopy/profa/work.RN3pBqek/.texlive2021/texmf-var/fonts/pk/ljfour/jknappen/ec# ll
total 8
drwxrwxrwx 2 www-data www-data 4096 Aug 2 14:35 ./
drwxrwxrwx 3 www-data www-data 4096 Aug 2 14:35 ../

So it looked like it tried to create the .600pk and succeeded in creating the directories but not the file. Note that at some point I changed all file permissions to 777 to see if this was a permission problem but that didn't help. Could the fact that everything is owned by www-data be causing problems?
In reply to Arnold Pizer

Re: pdfTeX error

by Glenn Rice -
It shouldn't be trying to create that file no matter what user runs pdflatex.

Why are you running pdflatex as root? What happens when you run pdflatex as your user?

The only directories in /opt/webwork/webwork2 that should be owned by the server user (www-data) are the DATA, logs, tmp, and htdocs/tmp directories. Really the server user just need read and write access for those locations. All others should be owned by your user, but readable by the server user (not writable). The server user should also own everything in /opt/webwork/courses.
In reply to Glenn Rice

Re: pdfTeX error

by Arnold Pizer -
No differences in site conf other than 
< $server_root_url = 'http:/192.168.138.129';
---
> $server_root_url = '';
230c230 < $database_password ='******';
---
> $database_password ='passwordRW';

$externalPrograms{pdflatex} = "/usr/bin/pdflatex --no-shell-escape";
which is what I ran successfully from the command line as root to generate output.
In reply to Arnold Pizer

Re: pdfTeX error

by Arnold Pizer -

Not sure if this helps, but if I go to a working directory

/opt/webwork/webwork2/tmp/myTestCourse/hardcopy/jsmith/work.5e5wwTod

and run

sudo -u www-data pdflatex ./hardcopy.tex

it creates the pdf and the missing font.  It places the missing font in a tmp directory under /

/tmp/texfonts/pk/ljfour/jknappen/ec/tcss0900.600pk

cd /tmp

drwxrwxrwt  3 www-data www-data 4096 Aug  8 15:54 texfonts/


What is different when WeBWorK runs the pdflatex command?

In reply to Arnold Pizer

Re: pdfTeX error

by Glenn Rice -

I see that the file /tmp/texfonts/pk/ljfour/jknappen/ec/tcss0900.600pk (and some other files in that directory) is created on my system when WeBWorK runs pdflatex as well.  I also tried deleting the entire /tmp/texfonts directory and then generating a hardcopy from WeBWorK again.  The files are recreated in the tmp directory, and hardcopy generation succeeds.

I do not see a .texlive2021 directory in the temporary working directory created by webwork.

I also noted that if I run pdflatex as my own user on the tex file generated by webwork, the files in the tmp directory are not created.  Instead there are files created in ~/.texlive2021/texmf-var/fonts/pk/ljfour/jknappen/ec.

In reply to Arnold Pizer

Re: pdfTeX error

by Steven Xiao -

I had the same problem with Ubuntu 22.04 LTS with the default settings. No hardcopies can be downloaded.

Once I ran 

 apt install texlive-full

it seems to me that all hardcopies can be downloaded which of course solved my problem.


In reply to Steven Xiao

Re: pdfTeX error

by Glenn Rice -

I don't think that the issue is with the packages that Arnold has installed.  I tested uninstalling all of the texlive package I have installed on my system and only installing the  texlive packages listed in the 2.18 installation manual (texlive, texlive-latex-extra, texlive-science, and of course their dependencies).  With just those installed, hardcopy still works fine for me.

In reply to Glenn Rice

Re: pdfTeX error

by Arnold Pizer -
Actually this is the issue.

I had tried
apt install texlive-full
but ran out of HD space on my small (20GB) vm. I also tried adding a texlive package (texlive-fonts-extra-links) without success. But after seeing Xiao's post, following https://gist.github.com/wkrea/b91e3d14f35d741cf6b05e57dfad8faf I installed texlive-full minus all documentation and language support except texlive-lang-english. This took about 3 GB's of additional space. As Steven reported, hardcopy generation now works.

Note that it worked previously if I ran pdflatex as root, www-data, etc but not using the WeBWorK interface.

Note that this is on a totally new installation of Ubuntu 22.04.3 following the Installation_Manual_for_2.18_on_Ubuntu documentation using Option 1: Serving Directly via Hypnotoad. I have not tested using Options 2 or 3.

I edited webwork2.mojolicious.yml setting
hardcopy:
preserve_temp_files: 1
but could not find the font tcss0900.600pk on my system. Note that the documentation on preserving_temp_files needs to be updated.

Pretty weird but something in texlive-full allows the WeBWork interface to work but is not needed for other users.
In reply to Arnold Pizer

Re: pdfTeX error

by Glenn Rice -

That most likely means something didn't install correctly to begin with when you installed the packages that are listed in the 2.18 installation manual, or that something is broken with your Ubuntu installation.  Most likely installing texlive-full fixed whatever went wrong when the other texlive packages were installed initially.

I have tested the packages carefully, and there is nothing more that is needed.  Furthermore, this works in a docker build which only contains the basic Ubuntu 22.04 installation with these packages.  That is essentially the same as running Ubuntu with webwork in a VM.

Note that it won't make a difference which of the serving options are used.  The app itself runs the same in all cases, and how it runs pdflatex will be the same.

What about the perserve_temp_files documentation do you think needs to be updated?  That setting preserves the temporary files created by webwork2.  It would not have anything to do with any temporary files which may be created by the system elsewhere like the /tmp/texfonts directory and any files within.

In reply to Glenn Rice

Re: pdfTeX error

by Arnold Pizer -

I have tried this multiple times always ending with the same error.  Xiao seems to have had the same problem.  I have always tried with a VMware vm.   If there is a real problem as I suspect, others will certainly find it.

As for the perserve_temp_files, in https://webwork.maa.org/wiki/Installation_Manual_for_2.18_on_Ubuntu#If_Something_is_Wrong,

If you do and have problems, edit the file Constants.pm in the directory /opt/webwork/webwork2/lib/WeBWorK. Change the line $WeBWorK::PG::ImageGenerator::PreserveTempFiles = 0; to ...::PreserveTempFiles = 1;

This is no longer valid for 2.18


In reply to Arnold Pizer

Re: pdfTeX error

by Glenn Rice -
You should try with a new Ubuntu 22.04 image and completely new webwork installation. I don't know how you are building the VMware vm, but there is something not installing correctly. I do not recommend installing texlive-full even with the method you used to skip the docs and language packs. There are also many other unnecessary things that will install. You might look through the other packages installed by docker. There are a few others that are not listed in the installation manual, and are dependencies of texlive-full that the docker build installs. They shouldn't be needed in general, and are added for other languages (like Hebrew), but there might be one that is needed that you are missing.

As to the documentation, I thought you were referring to the comments in the file conf/webwork2.mojolicious.dist.conf. I see that you are referring to the installation manual online. You rarely should use that option. It really isn't needed anymore. You can download the TeX source directly. I will update the documentation.
In reply to Glenn Rice

Re: pdfTeX error

by Glenn Rice -

Instead of installing texlive-full, just install the package cm-super.  I built a vm with virtualbox, and had the same issue that you are having.  After installing cm-super the problem was resolved.

This is a bit odd because I don't have that package installed on any of my servers, and hardcopy generation works fine on them.  So I suspect there are other packages that provide what is needed here also.

In any case I added that package to the installation manual for webwork 2.18.

In reply to Glenn Rice

Re: pdfTeX error

by Glenn Rice -
So it seems that it does matter which of the serving options that you are using on this. This will only happen if you are serving webwork2 directly via hypnotoad and using the Mojolicious::Plugin::SetUserGroup module, and that is the only case that you need the cm-super package. It seems to have something to do with the way that webwork2 app initially runs as root, and the plugin switches from the root user to the www-data user. This probably also has something to do with the fact that the www-data user is not a login user and doesn't have a home directory, as I noticed that the .texlive2021 directory is created in the working directory in /opt/webwork/webwork2/tmp in this case.
In reply to Glenn Rice

Re: pdfTeX error

by Glenn Rice -
Note that the cm-super package adds a font mapping that changes which system font is used for the tcss0900 font. It switches that to using /usr/share/texmf/fonts/type1/public/cm-super/sfst0900.pfb. That font is a type1 font to begin with, and the original tcss0900 is a metafont. That means that the tcss0900 font needs to be converted to work with TeX. Something with the way that the SetUserGroup plugin is switching from root to www-data makes it so that the converted font can't be found correctly. With the cm-super package, the converted font isn't needed (although it seems that the conversion still happens).
In reply to Glenn Rice

Re: pdfTeX error

by Arnold Pizer -
Thanks very much for tracking this down. I suspected something like what you found was going on but had no idea what and no idea how to track it down. My next try was to use option 2 for running webwork.

I will create an .ova image and a aws image. Seems like a few people use these, no idea how many. Is there any reason not to use option 1 in the images? The only one I can think of is if people use the same server for sending email.
In reply to Arnold Pizer

Re: pdfTeX error

by Glenn Rice -
Probably these images should use option 1 the same as the docker build does. Note that the docker build uses a slight variant on option 1 that does not use the Mojolicious::Plugin::SetUserGroup module. It runs the webwork2 app via "sudo -E -u www-data hypnotoad -f bin/webwork2" which is why this issue doesn't happen for the docker build. It can do this because it doesn't bind to port 80 directly. Instead it binds to port 8080, and so does not need to run as root initially. Port 80 or port 443 for ssl are externally exposed by docker.

Using option 1 shouldn't conflict with using the same server for sending email since that uses a different port.