Re: Automatic print routing aborting job
David McNicoll <mcnicoll-Y7yubSk0u6ZWk0Htik3J/[email protected]>
| Newsgroups | gmane.comp.printing.cups.bugs |
|---|---|
| Message-ID | <[email protected]> |
> 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 > Tried removing the buffers but, it had no effect. If you have any other ideas you think should be tried I would like to test them. Dave