Comment 1 Peter Åstrand 2014-11-26 16:10:56 CET

*** Bug 5368 has been marked as a duplicate of this bug. ***

Comment 3 Henrik Andersson 2015-02-23 09:08:51 CET

Just blindly fork and forget of a cups backend implies short circuit of error handling from backend to the cups service. Each print job will be successfully printed even those that fails.

The implementation should definitely do some error handling most obviously one are if the cups service is available or not at client. One problem here might be how to identify a disconnected client and a client with print redirection tuned off.

Comment 4 Henrik Andersson 2015-02-23 09:34:36 CET

(In reply to comment #3)
> The implementation should definitely do some error handling most obviously one
> are if the cups service is available or not at client. One problem here might
> be how to identify a disconnected client and a client with print redirection
> tuned off.

Found an issue and created bug #5441 which might affect this bug.

Comment 5 Henrik Andersson 2015-02-23 11:02:56 CET

Some investigation shows that the IPP backend provides a waitjob flag to control this behavior. If it's turned on IPP backend will wait for job print finish and report back to cups in a serial chain. If waitjob is turned off IPP backend will just push jobs to the remote queue and then exit with success.

Comment 6 Henrik Andersson 2015-02-23 11:15:23 CET

There is also an upstream bug where a delay of 5 seconds are performed.
  http://cups.org/str.php?L3495

This bug affects cups versions <v1.5, and would still affect the ThinLocal backend queue after we solved this bug. 

Maybe we could make a hack in ThinLocal backend overcome this delay problem by putting some data on the backend channel so that the wait loop always breaks out.

Comment 7 Henrik Andersson 2015-02-26 11:00:10 CET

The lpd client implementation for ThinLocal does try to allocate a privileged port if available to confirm to lpd protocol spec. If it fails to allocate a privileged port it will fallback and use unprivileged port. Due to the ThinLinc printing implementation, we can't handle this privileged port security and therefor this is code should be removed to make the case clear.

Comment 8 Henrik Andersson 2015-02-26 12:28:12 CET

It seems that there is no way to log into cups log files from the forked ThinLocal backend, the communication for backend to scheduler is performed via stderr.

Comment 9 Henrik Andersson 2015-02-26 14:21:24 CET

(In reply to comment #7)
> The lpd client implementation for ThinLocal does try to allocate a privileged
> port if available to confirm to lpd protocol spec. If it fails to allocate a
> privileged port it will fallback and use unprivileged port. Due to the ThinLinc
> printing implementation, we can't handle this privileged port security and
> therefor this is code should be removed to make the case clear.

Privileged port binding removed in commit 30049.

Comment 10 Henrik Andersson 2015-02-26 14:32:06 CET

Commit 30050 forks the sending of job to client to prevent clog of thinlocal queue.

The forking part lacks logging which needs to be taken care of. The only option is to create a new logfile for the thinlocal, however /var/log/thinlocal.log is not perfect. We should probably fix bug #4961 before introducing additional log files.

Comment 11 Henrik Andersson 2015-03-03 16:30:42 CET

(In reply to comment #10)
>
> The forking part lacks logging which needs to be taken care of. The only option
> is to create a new logfile for the thinlocal, however /var/log/thinlocal.log is
> not perfect. We should probably fix bug #4961 before introducing additional log
> files.

A decision was made to ignore the logging this release. Added the bug #5457 to reintroduce it in next release.

Comment 12 Karl Mikaelsson 2015-05-07 17:04:18 CEST

Here's how I tested this:

 - started tlclient with printer redirection active, logged in to a server
 - stopped tlclient.bin (^Z)
 - printed a text file
 - printer another text file
 - verified that there were one thinlocal process running for each printer job.
 - resumed tlclient.bin (fg)
 - watched the printer jobs get handled and printed by tlclient.bin.

That seems to work fine. I want to test a few more things before I'm content with closing the bug:

 - feedback for cases where printer redirection is off in the client
 - how long does the thinlocal jobs wait for?

Comment 15 Karl Mikaelsson 2015-05-11 14:20:39 CEST

(In reply to comment #12)
> Here's how I tested this:
> 
>  - started tlclient with printer redirection active, logged in to a server
>  - stopped tlclient.bin (^Z)
>  - printed a text file
>  - printer another text file
>  - verified that there were one thinlocal process running for each printer job.
>  - resumed tlclient.bin (fg)
>  - watched the printer jobs get handled and printed by tlclient.bin.
> 
> That seems to work fine. I want to test a few more things before I'm content
> with closing the bug:
> 
>  - feedback for cases where printer redirection is off in the client
>  - how long does the thinlocal jobs wait for?

There's no feedback, and given the lpd protocol we're using it's hard to do things better if we still want to have thinlocal work for more than one user at the same time.

I've found no other problems.