[cups] "Aborting job because it has no files."

[Szabolcs Csermák]

We are sending standard strings as raw. These strings contains
formatting in the language of the printer.
I am going to try it with a newer / older CUPS.

2016-11-24 16:09 GMT+01:00 Helge Blischke <helgeblischke at web.de>:
>
>> Am 24.11.2016 um 09:46 schrieb Johannes Meixner <jsmeix at suse.de>:
>>
>>
>> Hello,
>>
>> On Nov 23 21:30 Helge Blischke wrote (excerpt):
>>>> Am 23.11.2016 um 17:14 schrieb Szabolcs Csermák <csermak.szabolcs at gmail.com>:
>> ...
>>>> I [23/Nov/2016:17:02:32 +0100] [Job 18094] Job submission timed out.
>> ...
>>>> E [23/Nov/2016:17:02:32 +0100] [Job 18094] Aborting job because it has no files.
>> ...
>>>> D [23/Nov/2016:17:02:32 +0100] Securely removing "/var/spool/cups/a18094".
>>>> What does "job submission timed out" means?
>>
>> In the documenmtation of your particular CUPS version
>> see the various "timeout" related settings for cupsd.conf
>> perhaps you have a too short timeout setting somewhere?
>>
>>
>>>> We are using "lp" command in a loop, printing one ticket at every
>>>> time. So I we want to print 150 tickets, the lp command executes 150
>>>> times.
>> ...
>>> Perhaps your print job submissions occur too rapidly, so that some
>>> thresholds may be reached (max jobs e.g.).
>>
>> In the past I did a few tests with hundreds of thousands of jobs
>> that I submitted by a bash script as fast as possible to
>> hundreds of print queues that printout into /dev/null or into
>> files (via "FileDevice Yes" or via selfmade special backends)
>> but I never experienced a failure like the one described here.
>>
>> When thresholds like MaxJobs/MaxJobsPerPrinter/MaxJobsPerUser
>> are reached, the lp command fails to submit the job (which is
>> the expected and documented behaviour).
>> But when the lp command succeeds, I never experienced a failed
>> job afterwards.
>>
>> I did my above described tests with CUPS 1.5.4 and CUPS 1.7.5
>> (i.e. I did not test mass printing throughput with CUPS 2.x).
>>
>> To avoid misunderstandings:
>> With real printouts on real printer devices in real networks
>> there could be arbitrary weird failures for mass printing.
>>
>>
>> Kind Regards
>> Johannes Meixner
>> --
>
> Szabolcs,
>
> As these printers "speak“ a proprietary printer language that sounds (as for the abbreviation)
> fairly weird to me, please describe in more detail how the printer(s) are configured.
> Perhaps this information might lead to a solution?
>
> Helge
>
> _______________________________________________
> cups mailing list
> cups at cups.org
> https://lists.cups.org/mailman/listinfo/cups