したがって、私たちのオフィスチームがサポートする内部アプリケーションに使用されるいくつかのRedhat Enterprise Linuxサーバーがあります。これに加えて、サーバーは「syslog」という別名を持つCUPSプリンタを介して、ロギングシステムにさまざまなアクティビティに関する「自動印刷」レポートを送信します。
最近、アプリケーションをあるサーバーから別のサーバーに切り替えるまですべてが問題ありませんでした。その後、ロギングシステムがその環境で以前よりもはるかに少ないデータを受信していることがわかりました。すべての印刷ジョブが以前と同じようにほぼ直ちに処理されるのではなく、一部のジョブは完了するのに時間がかかり(作業ファイルは数十キロバイトを超えませんが、通常は10分以上)、ロギングシステムのWebページはサーバー側で「完了」します。いくつかの実験の後、4096バイト以下の印刷ジョブは正常に完了しますが、それより大きい印刷ジョブはほとんど中断され、目的地に到達できない可能性があります。私が言うことを明確にするのに役立つサンプルスクリーンショットは次のとおりです。
syslogプリンタの設定は現在のサーバーと以前のサーバーで同じように見えるため、これはトラブルシューティングに非常に混乱しています(また、以前のサーバーはVisibleにログインする直前に大きな印刷ジョブを処理できると言いました)。 1ジョブあたりのキロバイトは、ハードコーディングされた制限の問題だと思い、-o job-k-limit = 0オプションを使用してlpadminコマンドを使用してプリンタを再作成しましたが、あまり役に立ちません。 Linux SysAdminチームの誰かが「LimitRequestBody」というカップ設定を見つけて0に設定しましたが、それも役に立たないようです。
正直なところ、私たちはこの問題の原因が何であるかわかりません。火曜日に通信チームを派遣して、このサーバーとロギングシステムの間に潜在的なネットワーク問題があるかどうかを調べます。その間にどんなアイデアがありますか?
答え1
わかりましたが、パロアルトのファイアウォールの問題でした。ルールを追加しましたが、仕事が順調に進んでいます。良いもの!