CUPS: ghaaah!

So I have a postscript color printer. This is nice, because I can just throw postscript at it, and it will provide me with a hardcopy of whatever that postscript describes. Since postscript is what Unix-like systems like most, that's great.

Today, I needed to print something. It had been a while, and apparently some things in sid that are related to printing had changed, because it did not work anymore. I don't print every day (I absolutely don't print every day), so it had been, well, "a fair while" since I last used it. Of course it didn't work.

Of course, it is not the first time this happens. Every so often, my printer loses track with the cups installation on my server, and then I have to prod it a bit—usually by restarting the printer or the CUPS server, or both—and then it works again. The usual CUPS failure mode is that the printer was not available when I tried to print something, which causes CUPS to mark the printer as 'offline' or something, resulting in it being 'disabled'. The 'cupsenable' command is supposed to fix this, except that once in a blue moon it doesn't. I've learned to live with it.

But today was different.

Rather than the printer being disabled, something in the printer stack would just discard print jobs. That is, they would show up in the cups queue for a moment, and then disappear. I wouldn't get a piece of paper with something useful on it. I would just get nothing at all. This featureful printer supports syslog, and so I told it to send syslog messages to a useful system somewhere on the network. But that didn't produce anything interesting. It would tell me when the system had been powercycled, sure, but not why something would fail.

After trying many things for about an hour, sick of it all, I purged CUPS off my system and reinstalled it, then had it search for a printer again. It did find the printer through zeroconf messages, and I allowed the autoconfiguration stuff do things as it saw fit. When I asked it to print the exact same postscript file again, something came out of the printer. Finally, I thought, "success"!

Except it wasn't. Instead, the printer just produced gibberish. It turned out that cups had decided that my HP 2550n network-enabled postscript laserprinter was instead a HP 9xx-something USB-only PCL printer. Going back to the configuration interface and telling it to use the 2550n ppd file instead got me back to square one: the print job would appear in the print queue for a few seconds, then magically disappear.

At this point I was using 'tail -F' to monitor any logfile that might remotely be related. /var/log/cups/*, /var/log/syslog, /var/log/daemon.log, you name it. But nothing gave me any remote clue what was happening with the postscript that I'd been throwing at cups.

So I used netcat. This printer supports LPR, but will also accept postscript on port 9100 (I forgot what HP calls it), so a simple 'nc printer 9100 < foo.ps' should in theory just produce a printed page. And since someone told me that a "modern" (yeah, right) Linux printing system uses pdf throughout rather than postscript (for what, I don't know), I thought it might've been possible that something somewhere was just mangling the postscript in a way that things would not work anymore.

I was right, ut I never expected to e right in this manner.

Did you think this would be listed in the cups logs somewhere? Of course not! That would be too easy!

But then of course fixing this was fairly easy: just throw the original file from which this postscript was generated through a different postscript-generating program, and try again. Magic: suddenly the printer prints what I want! And it only took me 90 minutes.

Sometimes I wonder what the "userfriendly" police is smoking. Oh well.