[cups] What is the preferd method to connect cups 1.7.5 to cups 1.3.9

[Johannes Meixner]

Hello,

On Mar 1 10:53 Rick Cochran wrote:

> This may not be relevant to your problem, but ...
>
> Sometimes port 9100 connections from our (non-CUPS LPRng)
> server get stuck in a FIN-WAIT2 state, causing the queue
> to get stuck. This is rare, random, and  extremely annoying.
> It happens more with some queues than with others, and we switch
> those to LPD protocol, which doesn't seem to have this problem.
>
> You might want to check for this with netstat.

Many thanks for that hint!
It seems it points exactly into the right direction.


> On 3/1/16 4:18 AM, Johannes Meixner wrote (excerpt):
>> ... Pförtsch, Franz wrote (excerpt):
>>> device-uri lpd://<remote-server>/<remote-queue>
...
>>> It was working for hours, suddenly the spooljobs get stucked
>>> in the <local-queue>. The status of the queue was processing
>>> and the spooljobs showed "Data file sent successfully."
...
>> When the backend process runs endlessly for a stucked job
>> as next step you need to find out what exactly causes that
>> the backend process runs endlessly for that particular
>> print job in your particular environment.
>> 
>> Often when it mainly works but sometimes a backend process
>> runs endlessly for a particular print queue, the reason is
>> that the recipient (usually a printer device) does sometimes
>> not correctly tell the backend process that the print job data
>> was completely received - or something like that.

As far as I see when viewing the backend/lpd.c souces
after the "Data file sent successfully." message
(in case of the normal "ORDER_CONTROL_DATA",
  i.e. control file first, then data)
the lpd backend basically does nothing more
except to close the LPD socket connection
(via plain "close(fd)" where 'fd' is the LPD socket).

When the lpd backend process gets stuck in a FIN-WAIT2 state
(or more generally when it gets stuck in its socket close),
it would also explain why Franz Pförtsch was unable with
any "legal" methods (i.e. any CUPS coomads) to get rid of
the matching stuck job in the print queue (in order to
let the subsequent jobs in that queue print out).

When the lpd backend process gets stuck in a FIN-WAIT2 state,
(or more generally when it gets stuck in its socket close),
it would furthermore explain why neither Franz Pförtsch
nor I were able to reproduce it because we would need to
use a broken receiver that does not properly implement the
closing procedure (cf. "Normal Close Sequence / Figure 13."
in RFC 793).

But all this is currently only blind guess from my side.

What is needed is that Franz Pförtsch can find out what
exactly causes that the backend process does not finish
after "Data file sent successfully." in his particular
environment.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)