【徹底解説】lprは正常終了なのに印刷エラー？～CUPS利用における注意点～

トラブルの事例紹介です。
これを教訓にトラブル撲滅を目指しています。

今回のトラブルはこちら
「ユーザーから見ると帳票印刷済みとなっているにも関わらず、プリンターから印刷されない」

システム構成／処理シーケンス

1. ブラウザ上の印刷ボタンを押下／命令送信
2. apサーバへ命令送信（httpプロトコル）
3. lprコマンド実行
4. lprの正常終了により印刷ジョブを生成
5. lpr発行順にcupsのキューへ登録
6. プリンタへキューの送信（lprプロトコル）
7. 受信したキューをプリンタ上のキューへ登録
8. キュー登録順に印刷

トラブル内容

1.の結果、ユーザーのWebアプリケーション画面上では印刷実行結果が「印刷済み」となる。
しかし、実際は「8.印刷」がされておらず、Webアプリケーション画面の「印刷済み」と異なる。

直接原因

lprコマンドは正常終了しているが、cupsのキューが消失しており、プリンタまでキューが到達していない。
webアプリケーションはlprの実行結果（echo $の結果）だけで「印刷済」か「印刷失敗」を判断していたが、lprの実行結果だけではプリンタから印刷が完了しているか判断できない。

詳細解析

• cupsが、キュー最大滞留時間3時間を超えたキューを削除した。
  デフォルト設定の3時間、送信先物理プリンターが応答しない（送信要求を受けたあとのLPDレスポンス待ちなど）場合、サーバー上に登録されたキューを削除する

• 物理プリンター送信エラー時（フィニッシャーュ故障、紙詰まりなど）、送信リトライ5回×30秒を超えキューを削除する　　　

　　　　 /etc/cups/cupsd.conf　　　
　　　　    JobkillDelay=30　←　デフォルト　　　
　　　　　JobRetryLimit=5　←　デフォルト

対策

• キュー最大滞留時間を無制限に修正

　　　　MaxJobs　　　　MaxJobTime=0　←　無制限

• 送信リトライ回数を無制限想定

　　　 /etc/cups/cupsd.conf
　　　　JobkillDelay=864000　←　10日
　　　　JobRetryLimit=1000000　→　仮想無制限

• アプリケーションの「印刷済み」は、プリンターの印刷ログにおける「印刷完了」をもって判定する。

背景／考察

システム更改案件において、商用ソフトウェアSVFからOSS向け印刷システムcupsへの処理方式変更がありました。一方、機能、非機能に変更がない前提だったため、性能試験、負荷耐久試験は行っていません。しかし、実運用では数万ページの大量印刷が実行され、cupsキュー、プリンタキュー両方とも上限値に到達、長時間の印刷待ちが発生しました。

既存機能が実現できているのか試験はしていたものの、SVFより習熟度の劣るcups利用ということで設計、トラブル対応とも苦労したという事実があります。OSSを使うトレンドは継続すると思いますが、既存のソフトウェアからOSSへ移行する場合は注意が必要です。有償ソフトウェアはOSSより完成度（豊富な機能、流通している情報、サポート充実度など）が高く多くのメリットがあることを忘れてはいけないでしょう。

標準化／管理の定着

開発関連の実施要領に追加した一部を抜粋します。

• lprの正常終了により「印刷完了」とする業務ロジック自体が間違いである。設計はプリンタの印刷完了確認をもって「印刷完了」とする業務ロジックとする。
• 印刷量に応じたcupsキュー、プリンタキューのチューニングを実施する。（上限値にならない設定とすることで、lpr実行エラーの発生防止にもつながる）
• 帳票印刷試験の観点に「大量印刷」に関するユースケースを検討する。
  特にプリンタ管理ソフトおよびプリンタのキュー上限、プリンタ障害時の連続印刷などについて想定されるケースでの試験を行うことをお勧めします。

まとめ

プレプリント（テンプレートとなる代行収納用紙などに宛先、住所などの個別情報を後から印刷する帳票のこと）のように、印刷部数や専用プリンタを利用することが明確な場合は、想定印刷数による耐久負荷試験は実施すると思いますが、事務所で担当者がどういった使い方をするのか明確になっていない帳票印刷がある場合は、要件定義の性能／拡張性、運用性を必ず検討する必要があります。

特に今回のようにミドルウェア更改も含む場合、非機能要件に関する設定も引き継がれているのか十分確認しましょう。

コラム

今回選定したプリンターは、印刷順序に「データ受付順」と「データ処理順」の2モードがありました。
「データ処理順」を設定すると、以下のようなバグと思われる事象が内在していました。

メーカーは仕様だといってますが、明らかに動作がおかしい上、「データ受付順」の場合はこの事象は発生しません。こういったバグと思われるような事象をテストで発見することは難しい場合もありますが、設定値に対する負荷耐久試験は必ず実施し、品質を向上させる努力は必要です。

初歩的なトラブルを頻発させると、品質強化試験を迫られる場合があり余計な稼働がかかりますので、計画的な試験計画を立案するようにしてください。

ITエンジニアの転職ならNext Career（ネクストキャリア）がおすすめです。