Data truncation in print stream...

[Doug Slattery]

Ok, the problem has been solved.  Apparently the upgrade uncovered an existing known bug in one of the rpm's.  No need to continue pounding your heads on this one :).

Aloha,
Doug

> Hi,
>
> I'm having a sudden unexplainable problem that popped in this morning that was working Friday.  It's mostly unexplainable from the point that the only logical change was a software upgrade (not o.s.) on Friday afternoon.
>
> I'm using cups 1.1.17 on redhat es3.  There is a custom backend that takes the job, does some filtering on it and submits the filtered output to two other queues.  One of the queues archives the filtered data, which is all there.  The other queue converts it to pcl5 and sends it to a raw laser printer queue.  The problem occurs within the pcl5 queue.  The executable that does the pcl5 conversion is cutting short about the last 1k of data or so on every print job.  If I convert the filtered file to pcl5 from the command line, it is complete.  In the backend, I've tried redirecting the pcl5 data to a tmp file and submitting the tmp file to the laser queue.  Prior the pcl5 data was being piped directly to the laser queue.  The logs indicate everything is hunky-dory.  It's unlikely ram/diskspace as root has ~ 2GB free, /var has ~900MB free and /u has ~ 45GB free.  The ulimit is unlimited except for:
> max locked memory     (kbytes, -l) 4
> open files                    (-n) 1024
> stack size            (kbytes, -s) 10240
> max user processes            (-u) 7168
>
> It's got me baffled.  Anyone have any ideas???
> Aloha,
> Doug