Printing only works for PostScript files or CUPS' own test page

Bug #60931 reported by TEN on 2006-09-17
Affects Status Importance Assigned to Milestone
samba (Ubuntu)

Bug Description

System is Xubuntu 6.06.1 LTS.
Printer is a Brother HL-1650 (BRScript3, i.e. probably PostScript in all but name) over Samba (this does not seem to be an smbspool issue though).
CUPS can print its own test page.
lp works as well - but plaintext files ( takes some script code as an example) and attempts to print from applications (e.g. acroread, GIMP) result in stopped jobs.

BTW while the user might be expected to find http://localhost:631 (after some googling), it's been tricky enough to have to figure out
sudo adduser cupsys shadow
/etc/init.d/cupsys restart
to even be allowed to add a printer. This should probably be considered automagically in future versions...

I assume something goes wrong in foomatic's attempt to convert into PostScript and found the ways to make it write a debug log, but the parameters it is called with are a mystery to me (and apparently to itself either, judging from the output linked above) - so I can't tell yet whether it fails because of wrong parameters, missing input or insufficient rights to write its output.

Related branches

TEN (launchpad-20-ten) wrote :

The suspects - and indeed they've tried to escape:
" vs. '

In /tmp/foomatic-rip.log we have:

renderer command: level=0; /usr/bin/printf "%%!\n%%%% %%%%\n<</Duplex false>>setpagedevice\n"; if [ $level -gt 0 ]; then if [ $level -lt 99 ]; then level=" -dLanguageLevel=$level"; else level=""; fi; gs -q -dPARANOIDSAFER -dNOPAUSE -dBATCH -sDEVICE=pswrite$level -sOutputFile=- -; else cat; fi

This is from line 3567 of /usr/bin/foomatic-rip which tries to run:

See the nested, unescaped double quotes colliding...

Now even on the plain shell prompt we can only expect garbled output from
:~$ /usr/bin/printf "%%!\n%%%% %%%%\n<</Duplex false>>setpagedevice\n"
bash: !\n%%%%: event not found

...and nor does the following look right to me:
else cat; fi

Now if someone more familiar with that code could figure out where the /usr/bin/printf statements used in the invocations of rendercmd and the subsequent cmd and currentcmd are constructed, and if they are what makes the script fail
[at least it terminates without error, albeit without proper results as well, as soon as the above is changed to system('$commandline');],
I'd suggest replacing them with single quotes - rather than doing the same only for the system() calls which would make CUPS believe the jobs had been completed while producing empty output.

description: updated
Brian Murray (brian-murray) wrote :

Thanks for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Thanks in advance.

Brian Murray (brian-murray) wrote :

We are closing this bug report as it lacks the information, described in the previous comments, we need to investigate the problem further. However, please reopen it if you can give us the missing information and feel free to submit bug reports in the future.

Changed in cupsys:
status: Needs Info → Rejected
TEN (launchpad-20-ten) wrote :

Problem subsists in Ubuntu 7.04 "Feisty Fawn".

/var/log/cups/error_log has this:

I [05/May/2007:16:00:49 +0200] Adding start banner page "none" to job 8.
I [05/May/2007:16:00:49 +0200] Adding end banner page "none" to job 8.
I [05/May/2007:16:00:49 +0200] Job 8 queued on "HL-1650" by "user".
I [05/May/2007:16:00:49 +0200] Started filter /usr/lib/cups/filter/pstops (PID 20282) for job 8.
I [05/May/2007:16:00:49 +0200] Started filter /usr/lib/cups/filter/foomatic-rip (PID 20283) for job 8.
I [05/May/2007:16:00:49 +0200] Started backend /usr/lib/cups/backend/smb (PID 20284) for job 8.
E [05/May/2007:16:00:49 +0200] [Job 8] No ticket cache found for userid=1000
E [05/May/2007:16:00:49 +0200] [Job 8] Can not get the ticket cache for user
E [05/May/2007:16:00:49 +0200] [Job 8] Error writing spool: SUCCESS - 0
E [05/May/2007:16:00:49 +0200] PID 20283 (/usr/lib/cups/filter/foomatic-rip) stopped with status 9!
I [05/May/2007:16:00:49 +0200] Hint: Try setting the LogLevel to "debug" to find out more.

Can't seem to get /tmp/foomatic-rip.log anymore, despite setting
my $debug = 1;
in /usr/lib/cups/filter/foomatic-rip though.

Reopening this bug.
Reassigning to foomatic-filters.

> I [05/May/2007:16:00:49 +0200] Hint: Try setting the LogLevel to "debug" to find out more.

Please attach the output of the printingbug info script and your cups error log with LogLevel set to debug as described here:

To debug foomatic-rip you should set "debug: 1" in /etc/foomatic/filter.conf

Changed in cupsys:
assignee: brian-murray → pascal-devuyst
status: Rejected → Needs Info
TEN (launchpad-20-ten) wrote :

Attempting to print this very page from within Firefox (having incremented the above debug level) results in a /tmp/foomatic-rip.log containing
renderer command: level=0; /usr/bin/printf "%%!PS\n%%%% %%%%\n<</Duplex true /Tumble false>>setpagedevice\n"; if [ $level -gt 0 ]; then if [ $level -lt 99 ]; then level=" -dLanguageLevel=$level"; else level=""; fi; gs -q -dPARANOIDSAFER -dNOPAUSE -dBATCH -sDEVICE=pswrite$level -sOutputFile=- -; else cat; fi

Closing renderer
KID3 exited with status 0
KID4 exited with status 9
Renderer exit stat: 9
Process dying with "error closing *main::STDOUT", exit stat: 9
        error: Broken pipe (32)
$VAR1 = {
KID3 finished
Renderer process finished
Killing process 9475 (KID3)
Process dying with "Error closing renderer", exit stat: 9
        error: Bad file descriptor (9)
$VAR1 = {

Complete logs are attached.

Please try another driver.
Do you have the same problem with the PPD provided by Brother on the CD that came with your printer or can be downloaded from the Brother website according to
Your printer also supports PCL6 and should therefore work with the pxlmono driver. To set up your printer using this driver click System -> Administration -> Printers, add new printer, select make: Generic and model: Generic PCL 6/PCL XL Printer Foomatic/pxlmono.

TEN (launchpad-20-ten) wrote :

Using the PPD recommended above, the print job disappears without any apparent trace (no error recorded anymore in /tmp/foomatic-rip.log).

With the alternate driver, the attached log files/dumps are generated (see last entry on each), and a page is printed which reads:

PCL XL error

             Subsystem: KERNEL

             Error: Illegal Tag

             Operator: 0x25

             Position: 2249

TEN (launchpad-20-ten) wrote :

...whereas using the manufacturer-supplied PPD from (as referenced by - can only be unpacked / opened in "File Roller" / "Archive Manager" after "apt-get install rpm" of course) results in stopped print jobs ending up in the queue again.

I think you provided enough information to confirm this bug.

Changed in foomatic-filters:
assignee: pascal-devuyst → nobody
importance: Undecided → Medium
status: Needs Info → Confirmed

Can you try to connect the printer directly to your computer? Does it work then?

Can you check the printer settings on the Windows server? For printing from non-Windows clients you need to tuyrn off bi-directional printing on your Windows server.

Changed in foomatic-filters:
status: Confirmed → Needs Info
TEN (launchpad-20-ten) wrote :

I'm afraid there is currently no way to attach this printer to a local parallel port - the systems are at opposite ends of the network and premises, and rather immobile.

Suffice it to say that printing does work from Windows (both PostScript and PCL) as well as from other Linux systems (even ancient SuSE 8,2) and also locally on the server - which isn't Windows, of course, but the venerable OS/2 Warp 4.

Moreover, the fact that both the "CUPS v1.2.x Printer Test Page" and error messages when using the PCL 6 driver, as well as occasional badly rendered PostScript jobs (only some borders without text), do print over the network from the freshly installed Ubuntu 7.04 "Feisty Fawn" box, suggest that this is not a network problem (the reported, unresolved issue Samba 3 seems to have with OS/2 according to concerns file sharing).

TEN (launchpad-20-ten) wrote :

The start of each job actually does seem to get sent to the printer, as the HL-1650's LCD shows a green (i.e. informational) message such as "18 user SomeSite", i.e. apparently a job number followed by the user name and job name. Apparently the printer detects and discards the subsequent data as garbled in most cases before rendering the page (be it PS or PCL6).

Moreover, connecting an HP Deskjet 930C (i.e. a line rather than page printer) to the same server also shows only approximately half an inch printing (after pressing the page feed key blinking in orange), i.e. with a very different driver the job also gets stopped (even when printing the test pages, which works fine -i.e. printing the complete page without any error- on the HL-1650 in PCL6 from the context menu in System/Administration/Printers, as well as in PS from http://localhost:631/printers/HL-1650?op=print-test-page).

So I suspect some serious filter problem (as there apparently already was in 6.06) but I'm at a loss as to which debugging/logging steps to try&supply - any help appreciated.

Launchpad Janitor (janitor) wrote :

[Expired for foomatic-filters (Ubuntu) because there has been no activity for 60 days.]

TEN (launchpad-20-ten) wrote :

This issue had been auto-expired unresolved but persists.
Any info appreciated on how to proceed for debugging (jobs get lost/garbled somewhere between CUPS and smbclient printing).

Changed in foomatic-filters:
status: Invalid → New
TEN (launchpad-20-ten) wrote :

The following does work, making Samba (alone) an unlikely culprit.

smbclient //myhost/myprinter
smb: \> print
Error writing file: SUCCESS - 0
putting file as (984.4 kb/s) (average 984.4 kb/s)
smb: \> quit

TerryG (tgalati4) wrote :

Marked as Confirmed since this seems to be an intermittent issue.

Changed in foomatic-filters:
status: New → Confirmed
TEN (launchpad-20-ten) wrote :

It is (presumably depending on the job size) and the above "absolution" for Samba was premature, as some PS files will print through smbclient at least, while most others won't.

The Samba part of the issue probably ought to be addressed in #samba-technical and #samba-os2 on the IRC as well...

TEN (launchpad-20-ten) wrote :

According to testing of smbclient print commands against several OS/2 systems (conducted through irc://, larger jobs will be broken in at an (erroneous) upper size limit of 73 to 126kB (the precise figure is apparently machine-dependent).

If one is lucky, the printer will recognize and discard the larger jobs as incomplete (rather than wasting paper on them).

As the OS/2 printer queue may be advised to hold rather than print incoming jobs, these can be copied back from D:\SPOOL\MyPSprtr\*.SPL and compared against the original jobs e.g. using diff (-u) to reproduce the effects of this bug (which is presumably located within Samba).

Great, TEN, thank you very much for telling us about the patch. Then it is no problem to get this fixed in Hardy. I have milestoned this bug for Hardy now.

Changed in samba:
importance: Medium → High
milestone: none → ubuntu-8.04
Chuck Short (zulcss) wrote :

Working on intentraging this patch right now.


Changed in samba:
status: Confirmed → In Progress
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package samba - 3.0.28a-1ubuntu3

samba (3.0.28a-1ubuntu3) hardy; urgency=low

  * debian/patches/fix-smbprinting-os2.patch
    - Fixes printing large documents from OS/2. (LP: #60931)

 -- Chuck Short <email address hidden> Fri, 28 Mar 2008 08:37:31 -0400

Changed in samba:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.