Hi Phil,

On Mo 11 Apr 2011 10:26:16 CEST "--[ UxBoD ]--" wrote:

Agreed Mike; though I have the feeling it may be less worth than the
effort involved unless somebody knows the internal working of Perl
and SSHFS ? A sleep could be added though I have tried to avoid
slowing down the process to much. Since adding that loop code we
have not experiencing any further failures; though time will tell.

I already had a look at the printing code in x2go some time ago.

There basically are three components:

o cups-x2go o x2goprint o x2goclient

If I recall it corrently the interaction between cups-x2go and
x2goprint was not optimal then. I guess it was cups-x2go that left
over some print job files whenever a print job was sent to the client,
but I am not sure anymore. A person that was not in the x2goprint
group also created orphaned print jobs in /, because they were not
picked up properly by x2goprint. My observations all were a little
odd. Whenever I have time, I will take a look at the mechanism and
come up with some patches.

The x2goprint <-> x2goclient communication is rather simple: x2goprint
drops two job files in the spool dir: <job>.pdf and <job>.pdf.ready.
The X2go client has to run a thread that watches this spool dir (it's
in the x2go session cache folder under ~/.x2go/C-.../spooll). On each
incoming print job it has to wake up and take over the task of
processing the print job. My Python implementation of this printqueue
can be found here (if you prefer Python to Perl for a lecture...):

http://code.x2go.org/gitweb?p=python-x2go.git;a=blob;f=x2go/printqueue.py;h=...

Greets, Mike

--

DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...