"The printer has not yet responded..." with MS Office apps and iPrint

When launching Microsoft Office applications, users will periodically, or for a period of time, receive the following message:

The printer has not yet responded, but the Microsoft Office program may be able to proceed without printer information.  Do you want to continue to wait for the printer?

Regardless of selecting yes or no, the user will not be able to print.

A packet trace of the situation shows many IPP requests, to which the server ACKnowledges, but an IPP response is seldom seen, or takes a great number of IPP request retries are seen before an IPP response is returned.

In the /var/log/apache2/error_log, the following message is seen a number of times:
[warn] child process 14592 still did not exit, sending a SIGTERM

and after an Apache2 restart:
[error] server reached MaxClients setting, consider raising the MaxClients setting

The quickest way to resolve the situation is to increase the number of MaxClients and restart Apache2.  For reference, the MaxClients setting is found in a couple of places within /etc/apache2/server-tuning.conf .  To change this setting, please do the following:

1. Verify whether you are running "worker" or "prefork" multi-processor modules (or MPM).
   To do so, run "/usr/sbin/httpd2 -l" (that's a lower case L).  You should see output similar to:
   Compiled in modules:
     core.c
     worker.c
     http_core.c
     mod_so.c
   If the second line indicates "worker.c", you are running worker MPM. 
   If the second line indicates "prefork.c", are running prefork MPM.
2. Edit the /etc/apache2/server-tuning.conf file.
3. If you are running worker MPM (the default), increase the MaxClients under"# worker MPM " by 50 threads (not to exceed 400). 
4. If you are running prefork MPM (the default), increase the MaxClients under"# preform MPM " by 50 threads (not to exceed 400). \
5. stop Apache2 (rcapache2 stop )
6. start Apache2 (rcapache2 start )

This will alleviate some of the pressure on Apache2 client threads and allow the server to take a larger load.

To address the root cause, you will want to check for the typical bottlenecks including:

• congestion on the WAN
• congestion or bad port on the LAN (i.e. switch)
• lack of memory in the server (look for increased swap space utilization)
• high cpu utilization
• high disk i/o

In some cases, the machines/clients accessing Apache may take longer to complete the tasks than expected which will tie up a client thread (one of MaxClients) and cause the number of concurrent threads to climb.  This will lead to thread exhaustion and inability to service new requests (hence the lack of an IPP response above).

In the case of iPrint, the iPrint client will retry after approximately every 5 seconds until it times out (which exacerbates the condition).  In looking at a 30 second trace, one workstation could have 7 IPP requests -- the initial plus 6 retries -- each of which adds load to the apache processes.