The Common Unix Print Server (CUPS) has become the standard in Linux. Line Print (LP), although frequently used in Sun shops, is lightweight and easy to use, but lacks support and development. LP provides great command line options; however, with the advent of a graphical user interface (GUI) World, the command line has been superseded by the “click”. CUPS provides the “click” consideration, but Administrators need to address printer quotas and file system considerations.

File system considerations? Just install cups and you are done. Right? Not necessarily, because you need to consider a couple of very important aspects of a print server spool directory, input/output (IO) and number of files. I/O is a concern due to the spool directory being a pass-through directory. The number of files is a concern, because the spool directory could be expected to manage tens-of-thousands of files if you are printing labels. Here are a few recommendations to think about:

• What is the fastest disks we have for the spool directory?
• Are there other applications running on the server?
• Create “/var/spool” on a separate partition?
• What file system format will provide the least overhead and handle the number of files we will be sending to the print server spool directory?
• Did you create an exclusion directive in netbackup for the spool directory? I would not back up the spool directory, because it should be empty (unless there is a problem) and the competition for I/O on the file system may result in printer slowness.
• Did we create a cronjob to monitor the file system and alert someone when the number of files is building? Monitoring and notification are excellent methods to know when CUPS, network and or a printer is experiencing problems and for “tweaking” configurations.

Configurations are a concern when dealing with the health of CUPS. CUPS has default quotas in the cupsd.conf file. Adjustments are required for enterprise deployment. I would recommend the following adjustments:

1. PreserveJobHistory Yes TO PreserveJobHistory No . This might seem like a great option to keep on or use the default “Yes”, but this can cause problems with another setting. If a job has gone to the printer and printed, why save the job? This will not effect the jobs in the queue if a printer goes down or is unreachable.
2. MaxJobs 500 TO MaxJobs <what ever number you will have at one time in the spool directory>. You need to set this up to the max number of jobs from all printers at one time and give yourself a buffer. If the CUPS spool directory hits this number, CUPS will stop working on print jobs. You will need to stop cups, delete the old files in the spool directory and restart cups. If you keep the default PreserveJobHistory setting, CUPS will include old jobs in the MaxJobs count.
   Why not set it to 0 (unlimited)? If you do not perform routine maintenance on the spool directory, it will fill if there is a printer issue. If you did not place “/var/spool” on a separate directory as recommended, you will need to use a recover CD to mount “/” and clean up the spool directory in order for your system to restart.
3. MaxJobsPerPrinter 0 TO MaxJobsPerPrinter <your value>. This is a tricky setting if you are printing labels. If the label printer goes down and jobs are still being sent to the label printer you could fill the spool directory if the setting left at unlimited. Not to mention you will hit your MaxJobs setting and have to clean-up CUPS.

After reading this article, you should have a good understanding of what is required to ensure a healthy CUPS environment in regard to file system and printer quota consideratios. Please leave comments about how you resolved problems with your CUPS environment. As always, please patronize the sponsors of this page. They make this possible.