Hello, On Nov 5 09:43 Jack Malone wrote (shortened):
I'm using suse 9.1 here on our production server with samba running. Its seems several times a month printing will stop to one or all of the printers I have attached via network to this server. To solve the problem I kill all cupsd, then go into the queue an delete all old an current print jobs in the queue, then restart cupsd. Then I go an send a test print job from server to one or two of the printer an everything works again til the next time it happens. It was only happening once a month but now it seems to happen more often.
I.e. you print from Windows client machines via Samba to a Linux CUPS server and some strange print jobs which are sent from a Windows client machine can cause the whole CUPS system to hang up somehow. I guess that it is the CUPS filtering system which gets somehow confused because for the filtering system the content of a print job does matter. In contrast the CUPS spooling system only receives and forwards data and for the spooling the content of a print job should not matter. The crucial point is how you do the filtering. Normally the filtering takes place on the Windows client machines and you must make sure that there is no additional filtering on the CUPS server. When you print for example a PDF on a Windows client machine and you have the printer specific driver installed on the Windows client machine then it is no longer PDF which arrives at the Linux CUPS server but it is arbitrary printer specific data. Here a quote from two longer explanations which I sent to someone else: ====================================================================== The problem is that the admin has several choices what to set up. To choose the correct stuff depends on the actual situation and the wishes of the admin. Therefore there is no one best way. Therefore the admin needs understanding of the possibilities. The real reason of all this problems is that the design how printing works under Unix/Linux is different from how it works under Windows. The admin must learn to keep spooling (the plain data buffering and the plain data transfer) and filtering strictly seperated in her mind. Network protocols are only related to spooling. Printer drivers are only related to filtering. Of course spooling and filtering must cooperate to get a printout but they are two different things. Mixing up spooling and filtering causes so many confusion and so many misconfigurations (and complaints about "bugs" which are in fact only misconfigurations) result from this confusion. The crucial design difference is: Under Unix/Linux: The client systems send the original data (e.g. plain text, PostScript, JPEG) to the print server (to a print queue via LPD or IPP protocol) and the print server converts it into the printer specific format (the so called "filtering") and sends the printer specific data to the printer. I.e. the print server does spooling and filtering. Under Windows: The client systems convert the original data (e.g. plain text, MS-Office documents, whatever-proprietary-formats) into the printer specific format and then send the printer specific data to the print server (to a printer share via SMB protocol) and the print server sends the printer specific data to the printer. I.e. the print server does only spooling. The filtering is done on the client systems. Consequences: Under Unix/Linux: The client systems don't need to care about the actual printer model. It is only the print server which is responsible to do the model specific stuff. This is THE advantage of the design under Unix/Linux. If an end-user has a laptop and connect it to a new network where a CUPS server is running and if the end-user runs her own cupsd on her own laptop, then she can immediately print. See "Intrinsic Design of CUPS for Printing in the Network" under http://portal.suse.com/sdb/en/2004/05/jsmeix_print-cups-in-a-nutshell.html Under Windows: The client systems must care about the actual printer model. I.e. printer drivers must be installed on the client systems. This is THE drawback of the design under Windows. Consider the problems when printers are added or exchanged: Special software stuff (provide drivers for download) and special end-user actions (driver installation/replacement) are needed to deal with this situation. If an end-user has a laptop and connect it to a new network, then she cannot print without doing driver installation before. Perhaps she doesn't want to download drivers from an unknown/untrusted network system - what should she do? Assume there is a network with Windows client systems and a Linux print server should replace a Windows print server then the following must be done on the Linux print server: I) Regarding the plain data transfer from the Windows client systems to the printers (the "spooling"): Spooling works without software which is called a "printer driver". A) For each printer there must be a matching print queue on the Linux print server. B) For each print queue on the Linux print server there must be a matching printer share so that the Windows client systems have the usual receiver to which they can send their printer data. Those printer shares are provided by Samba. Alternatively the Windows client systems may be changed to send their printer data not to a printer share via SMB but directly to a print queue via LPD or IPP protocol. If all Windows client systems are changed this way then there is no need for Samba on the Linux print server. It is no problem to let some Windows client systems send their data via SMB/Samba to the print queue and let other Windows client systems send their data directly to the queue via LPD or IPP protocol. II) Regarding the conversion from the original data into printer specific format (the "filtering"): Here software which is called a "printer driver" is needed. Either) The filtering is still done on the Windows client systems: Then the Windows client systems produce printer specific data. Printer specific data is often random binary data. A normal print queue on the Linux print server does not accept random binary data because the Linux filtering system would not know how to convert this into printer specific data (remember the design difference above). As printer specific data can be of random format (from random binary data up to PostScript or PDF) it is not possible to have a general autodetection mechanism for printer specific data. Therefore: When the filtering is done on the Windows client systems, then the Linux print server must be forced not to try to filter it again but to send it directly to the printer. This is called "raw" printing (i.e. "raw" means "without filtering"). The CUPS printing system can be forced to do "raw" printing by using the "-o raw" switch in the printing command (e.g.: lp -d queue -o raw file-in-printer-specific-format). If the Windows client systems send their data via SMB/Samba then there is an option (as far as I know this is set by default) in /etc/samba/smb.conf to enforce raw printing: cups options = raw This way Samba which got the printer specific data via SMB would forward it in raw printing mode to the print queue and therefore the CUPS printing system will send it directly (i.e. without additional filtering) to the printer. If the Windows client systems send their data via LPD to a CUPS print server then the raw option can be set in the configuration for the cups-lpd (this is the daemon which accepts data via LPD for CUPS) - see "man cups-lpd" -o document-format=application/vnd.cups-raw All data which has the MIME type "application/vnd.cups-raw" is not filtered but sent directly to the printer. If the Windows client systems send their data via IPP to a CUPS print server then it depends whether or not a raw option can be set in the Windows IPP software. If it cannot be set on the Windows client system then the only reliable way to enforce raw printing on the CUPS server is to create for each printer an additional "raw" queue on the CUPS server (there is a manufacturer "Raw" selectalbe when adding a printer via CUPS web-frontend or in YaST you can set up a queue without filtering) and let the Windows client systems send their data to this "raw" queues. If there are only Windows client systems in the network then it is sufficient to have only "raw" queues. Or) The filtering should be done on the Linux print server: Normally the filtering system on a Linux print server cannot convert MS-Office documents or whatever-proprietary-formats into printer specific data because there is no approriate filtering program available. Normally the filtering system on a Linux print server accepts plain text, PostScript, JPEG (and some other graphics formats). Therefore the Windows client systems must produce one of those accepted formats. As PostScript is THE standard printing language under Unix/Linux the usual solution is to install a special kind of filtering (i.e. a special kind of printer driver) which produces PostScript on the Windows client systems. In most cases one of the following two PostScript printer drivers are used on the Windows client systems: The "CUPS Driver for Windows" - see http://www.cups.org/windows.php or the "Adobe PostScript printer drivers" - see http://www.adobe.com/products/printerdrivers/main.html Result: When the filtering should be done on the Linux print server then there must be also a pre-filtering-into-PostScript done on the Windows client systems. ---------------------------------------------------------------------- Please note that I described only the usual case! The following is background information. You may ignore it because it may become too complicated. But please have in mind that there are some other possibilities and refer to the Samba-HOWTO for more information. Of course it is possible to convert the original data into the printer specific format on a Linux client system and let the Linux print server do only the spooling. This must be done when a Windows SMB print server is used, see http://portal.suse.com/sdb/en/2003/11/jsmeix_print-smb-90.html When CUPS is used both is possible (filtering on the client or on the server) but usually the filtering is done on the server. And it is possible to a certain extend to do the conversion into the printer specific format on a Windows NT print server: Not from the original data into printer specific data but from EMF format into printer specific data. The drawback is that the EMF format is to a certain degree printer dependent: Note the "driver info" in the pictures below. See http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/CUPS-pr inting.html#id2561305 or for bigger pictures see http://www.linuxprinting.org/kpfeifle/SambaPrintHOWTO/Samba-HO WTO-Collection-3.0-PrintingChapter-11th-draft.html#14_8_1 PostScript is the standard printer language under Unix/linux. To a certain degree EMF is the analogon under Windows. See http://www.linuxprinting.org/kpfeifle/SambaPrintHOWTO/Samba-HO WTO-Collection-3.0-PrintingChapter-11th-draft.html#14_6_1 The case "Driver Execution on the Server" under Windows http://www.linuxprinting.org/kpfeifle/SambaPrintHOWTO/Samba-HO WTO-Collection-3.0-PrintingChapter-11th-draft.html#21_3 is the analogon to what I described later under "The filtering should be done on the Linux print server:" The Windows NT possibility "Driver Execution on the Server" can be transformed into what I described under "The filtering should be done on the Linux print server:" and the matching picture is here http://www.linuxprinting.org/kpfeifle/SambaPrintHOWTO/Samba-HO WTO-Collection-3.0-PrintingChapter-11th-draft.html#14_8_2 In contrast the usual Windows case "Driver Execution on the Client" http://www.linuxprinting.org/kpfeifle/SambaPrintHOWTO/Samba-HO WTO-Collection-3.0-PrintingChapter-11th-draft.html#21_2 can be transformed into what I described under "The filtering is still done on the Windows client systems:" ====================================================================== Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: jsmeix@suse.de 90409 Nuernberg, Germany WWW: http://www.suse.de/