![为什么我的 CUPS 打印机在打印大于 4 KB 的打印作业时会停止运行并失败?”](https://linux22.com/image/221907/%E4%B8%BA%E4%BB%80%E4%B9%88%E6%88%91%E7%9A%84%20CUPS%20%E6%89%93%E5%8D%B0%E6%9C%BA%E5%9C%A8%E6%89%93%E5%8D%B0%E5%A4%A7%E4%BA%8E%204%20KB%20%E7%9A%84%E6%89%93%E5%8D%B0%E4%BD%9C%E4%B8%9A%E6%97%B6%E4%BC%9A%E5%81%9C%E6%AD%A2%E8%BF%90%E8%A1%8C%E5%B9%B6%E5%A4%B1%E8%B4%A5%EF%BC%9F%E2%80%9D.png)
因此,我们有几台 Redhat Enterprise Linux 服务器用于我们办公室团队支持的内部应用程序。除此之外,服务器还通过绰号为“syslog”的 CUPS 打印机将各种活动的“自动打印”报告发送到日志系统。
一切都很好,直到最近,我们将应用程序从一台服务器翻转到另一台服务器,从那时起,我们注意到日志系统在该环境中接收到的数据比以前少得多。所有打印作业不再像以前那样几乎立即得到处理,而是其中一些作业现在需要一段时间才能完成(尽管作业文件不超过几十千字节,但通常需要 10 分钟以上),而且甚至不会显示在日志系统的网页一旦在我们的服务器端“完成”。经过一些实验后,我注意到 4096 字节或更低的打印作业仍然可以顺利完成,但任何大于该字节的打印作业很可能会停滞并且永远不会到达目的地。这是一个示例屏幕截图,如果它可以帮助澄清我在说什么:
这对于故障排除来说非常令人费解,因为系统日志打印机的配置在当前和以前的服务器上似乎是相同的(并且说以前的服务器几乎可以立即处理更大的打印作业,然后它们在日志记录中可见)系统也)。我认为这是每个作业的硬编码限制千字节的问题,因此我们通过带有选项 -o job-k-limit=0 的 lpadmin 命令重新创建了打印机,但这似乎没有帮助。 Linux SysAdmin 团队的某人还发现了一个名为“LimitRequestBody”的 cups 设置并将其设置为 0,但这似乎也没有帮助。
坦率地说,我们不知道造成这种情况的原因是什么。周二我们将派电信人员调查该服务器和日志系统之间是否存在任何潜在的网络问题,但与此同时,如果你们有任何想法的话。
答案1
事实证明这是帕洛阿尔托防火墙的问题。添加了一条规则,现在事情进展顺利。好东西 !