Re: Automatic print routing aborting job

David McNicoll wrote:

>> David McNicoll wrote:
>>
>> >> David McNicoll wrote:
>> >>
>> [...]
>> >
>> > All starts well with the first few jobs printing [Job 3280] then ends
>> > with
>> > the last job failing [Job 3283].  Even after the last job fails, the
>> > automatic print routine continues to run and print more packing slips
>> > with
>> > an occasional failure.  According to our ERP vendor the automatic
>> > program is designed to run the same manual printing steps that would be
>> > performed by an operator. The printouts are simple text, no graphics.
>>
>> Well, from your log I think the issue is due to some flaws on the path
>> from the ERP application to CUPS.
>> Could you please give more information on how this is configured?
>> Is your ERP app possibly running on a Windows box and thus SAMBA in
>> between?
>>
>> Helge
>>
> Our ERP software runs a GUI telnet client from our Windows stations to the
> Linux box, so I'm guessing SAMBA gets involved.  Here is our smb.conf
> file:
> 
> # Global parameters
> [global]
>         workgroup = WORKGROUP
>         server string = ERP Server
>         security = SHARE
>         password server = None
>         username map = /etc/samba/smbusers
>         log file = /var/log/samba/%m.log
>         max log size = 50
>         socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
>         printcap name = /etc/printcap
>         dns proxy = No
>         create mask = 0666
>         directory mask = 0777
>         guest ok = Yes
>         cups options = raw
>         load printers = yes
>         printing = cups
> 
> [homes]
>         comment = Home Directories
>         read only = No
>         browseable = No
> 
> [printers]
>         comment = All Printers
>         path = /var/spool/samba
>         printable = Yes
>         browseable = No
> 
> This .conf file was copied over from our RHEL 3 box.
> 
> Dave

The samba configuration seems to be OK. I'd suggest to comment out the 
socket options parameter and see if that fixes the issue; it may be that the 
system default receive and send buffers are more approriate than your 8192 
values.

Helge