CUPS stops printing right after a while

Question

I've converted an automatic printing system from Windows with Acrobat Reader to Ubuntu with CUPS. This took about 10 minutes using CUPS, but now I'm getting a strange issue with incomplete prints rolling out, or nothing being printed whatsoever after a while. CUPS reports seemingly arbitrary errors. Sometimes it doesn't even report an error, and most of the errors reported are "broken pipe" errors.

Usually after adding a printer to CUPS it will print fine for a while. When I come back a few hours later and try the exact same thing (even with the same file), the file might not print at all or come out of the printer with elements missing.

This might be an unrelated bug, but also after a while CUPS' web interface stops responding. All I can access after this happens is the HTTP version of the main page. A restart of CUPS fixes this.

I'm running a fresh installation of CUPS, with only remote administration enabled. The issue persists even after doing a sudo service cups restart.

I've added the printers in many different ways (socket, ldp, ipp), with both generic PCL6 drivers and the printers' official KPDL drivers. Directly after adding a printer the prints will usually come out as expected. I'm printing using the most basic command possible: lp -d [printer-name] [numbers].pdf.

I'm running Ubuntu Server 16.04. The printers I've configured are a Kyocera ECOSYS FS-1370DN, and a Kyocera ECOSYS P2135dn. The printers do not seem to be the issue though, as a HP printer I've used exhibits the same issue.

I've been trying to figure out what is going wrong for longer than I care to admit. And I'm starting to feel pretty stupid. Every time I think I've fixed it bad prints start rolling out soon after. Acrobat Reader/the Windows print spooler never has trouble printing, even while CUPS spits out garbage.

Other things I've tried without success: - Converting to PostScript (.ps) using pdf2ps before printing - Converting to PDF using GhostScript (fixing possible PDF errors) before printing - Printing web-downloaded test PDFs known to have printed well before.

This is the weird one that's defying all logic to me: Uploading the PDF files through ftp (the printers are capable of printing PDF) also only works sometimes. This completely circumvents CUPS, so it must be the printers right? But no, printing the same file through Acrobat Reader works fine.

As it stands the only option I see is to convert the Ubuntu server to a VM with an expensive Windows Server VM running alongside it, only used for printing... There must be a solution to this issue.

EDIT: I've set up CUPS on my Ubuntu Server 16.04 at home and configured a Canon MG8100 on it. The first few prints came out fine. The next morning, every job I added showed it completed, but actually nothing came out of the printer. This means it does not have anything to do with the printers. I added the MG8100 using LPD.

CUPS error log states the below errors. Keep in mind that all these errors occur for the exact same file on different times, and that the file was printed successfully in the same manner before.

E [26/Nov/2016:13:35:44 +0100] [Job 158] The printer is not responding.

When this is logged no print is made and CUPS keeps retrying the job until it is abandoned. Other times it fails like this:

W [29/Nov/2016:11:45:01 +0100] [Job 169] /var/spool/cups/d00169-001: file is damaged
W [29/Nov/2016:11:45:01 +0100] [Job 169] /var/spool/cups/d00169-001 (file position 35596): xref not found
W [29/Nov/2016:11:45:01 +0100] [Job 169] /var/spool/cups/d00169-001: Attempting to reconstruct cross-reference table

Which will result in a mangled print (Random parts being printed, and others being left out).

Answer 1

As one of the many attempts to fix the issue I have included Verdana as a font in the generated PDFs instead of letting Linux substitute it with Nimbus Mono L. So far printing has worked correctly for five days now. I'm posting this answer and would welcome any speculation or an answer as to why this is happening.

I have access to the printing setup in a few days, where I will look at the logs and other data. Of course this situation could also be a coincidence and the printing system can happily start mangling prints as soon as I post this. I've taken that chance.

This would also not explain why test pages are not printing right. This might be because they also contain fonts not compatible with the printer, or that the error occurs for everything after it has happened once. It's quite far fetched, but I'm leaving all options open at the moment.