Section 7.10. Printing, Queue Lists, and tdb Files

7.10. Printing, Queue Lists, and tdb Files

Samba has always played the role of masquerading Unix hosts as Windows servers. This role requires that certain Unix attributes be extended to present the information expected by Windows clients. Printing is no exception. Samba places a thin layer over Unix print jobs to store the additional information, such as the CIFS print job's numeric ID, the name of the print job (rather than the spool file name of smbprnXXXX), and the Windows security descriptor associated with the document in the queue. This information is maintained in each printer's queue cache database, located in the printing subdirectory of Samba's lock directory. These cache tdbs are used to enumerate job listings to clients such as the print queue monitor shown in Figure 7-9.

Figure 7-9. Listing of jobs in a Samba print queue from a Windows client

It can be expensive to reparse the output from the lpq command every time a client asks for an update on the status of a specific printer. The solution to this is to respond to the client request out of cache. This means that there is a lag between the real state of the Unix print queue and what is displayed to the Windows client. This lag is controlled by the integer value of the lpq cache time parameter. This value represent the expiration time in seconds of the cache file tdb contents. Current Samba releases default to a 30-second TTL.

Be very careful when tweaking this parameter. A smaller value may provide more accurate data to clients, but on a busy server with a large number of printer, the cost in CPU time is significant.

Sometimes it is desirable to restrict the maximum number of jobs accepted for a given queue. This can be done by defining the max print jobs option in the smb.conf print service. Setting the parameter to 0 (the default value) indicates that there should be no limit on the number of print jobs in the queue at any given time.

It is also possible to allow an unlimited number of jobs in the printer but restrict the number of jobs reported to a client by setting the max reported print jobs option. This is another performance tweaking option. It saves Samba from spending all its time composing a list of jobs to send back the client, only to find that by the time it finishes the list, its cache has already become outdated. Again, a value of 0 indicates that Samba should simply report the complete set of jobs without any restrictions on the list size.

You can thank the test engineers who believed Samba should scale to support more than 10,000 jobs in any given print queue at a time for these parameters. Of course, if you have that many jobs in a print queue, you probably have other problems with the printer. But at least Samba will happily report the situation and continue to do normal work.