対象とするUbuntuのバージョン
- すべて
注:この文書は DebuggingPrintingProblems の翻訳です。
バグの報告
Jaunty Jackalope こと 9.04 より、'ubuntu-bug cups' を用いてバグをレポートすることで、例えば Ubuntu のバージョン、設定済のプリンター、主要な印刷関係のパッケージのインストール済バージョンなどといったシステムの情報を自動的に集め、バグレポートに添付します。また、バグをレポートしたあとでも、'apport-collect -p cups BUGNUMBER' を実行することで情報を追加することができます。ここで BUGNUMBER は情報を追加したいバグレポートの番号です。
Intrepid Ibex こと 8.10 あるいはそれ以前では、バグレポートに https://wiki.ubuntu.com/PrintingBugInfoScript にある printingbuginfo スクリプトの出力結果を添付しましょう。このスクリプトは上で示した ubuntu-bug および apport-collect で利用されている cups apport hook と同じような情報を手動で収集します。
Intrepid から、cupsys パッケージは cups に名称変更されました。Interpid (8.10) 以降のリリースでのバグは cups パッケージに割り当てられ、それより前のバグレポートは cupsys に割れ当てられています。
プリンタの検出
USBプリンタ
- プリンタがUbuntuシステムに接続され、電源が入っていることを確認してください。
ターミナル/コンソールを開き、USBのカーネルモジュールがロードされているか確認してください:
$ lsmod | grep usbお使いのコンピュータからUSBプリンタケーブルを抜いて次のコマンドを入力します:
$ tail -f /var /log/syslog- USBプリンタケーブルを再接続すると、いくつかのメッセージが現れるはずです。
- Ctrl - Cを押して、ログ取得を停止します。
プリンタが正しくUSBサブシステムによって検出されるかどうかを確認し、そのUSBのベンダー/プロダクトIDとUSBのバスとデバイスのアドレスを調べます:
$ lsusb
注:USBプリンタをオフにするか、取り外すととデバイスのアドレスは変更されます。必要に応じてこのコマンドを再実行してください。プリンタ用のデバイスファイルが作成されており、所有権("root lp")とパーミッション(HP以外: "crw-rw-r--", HP: "crw- rw-r--+"))が正しいかを確認します:
$ ls - l /dev/lp/* /dev/usb/*プリンタのデバイスID文字列を調べます:
$ sudo usb_printerid /dev/usb/lp0
$ sudo usb_printerid /dev/usb/lp1
...
HPのプリンタの場合は
$ hp-info -i
を使って、テキストメニューから問題のあるプリンターを選択し、"deviceid" エントリーを出力結果(複数行かもしれません)からコピーしてください。HPのプリンタの場合:HPLIPがプリンターに正しく接続されるかを確認してください:
$ hp-makeuri <Bus>:<Device>
"<Bus>"と"<Device>"は "lsusb" の出力のバス番号とデバイス番号と置き換えてください(ベンダーIDとプロダクトIDではなく)。これらの番号は"008:015"のように、0で桁埋めされた三桁の数字のはずです。プリンタがCUPSによって検出されるかどうかを調べます:
$ lpinfo -v- バグレポートに上記のコマンドの出力を添付してください。
問題は CUPS だけで起こっているわけではなく、カーネル (パッケージ "linux")、libusb、HPLIP (パッケージ "hplip")、その他サードバーティ製プリンタードライバーでも起きうるということに注意してください。
パラレルポートのプリンタ
- プリンタがシステムに接続され、電源が入っていることを確認します。
ターミナル/コンソールを開き、lp, ppdev, parport_pc の各カーネルモジュールがロードされているか確認します:
$ lsmod | grep lp
$ lsmod | grep ppdev
$ lsmod | grep parport_pcカーネルがブート時にパラレルポートを検出したかどうか確認します:
$ dmesg | grep parパラレルポートのデバイスファイルが作成され、正しいアクセス権と所有権を持っているかどうか確認します:
$ls -l /dev/lp* /dev/parport*プリンタの自動検出結果が、カーネルの仮想ファイルシステムに表示されているかどうかを確認します:
$ ls -l /proc/sys/dev/parport/parport*/autoprobe*
$ sudo cat /proc/sys/dev/parport/parport*/autoprobe*プリンタがCUPSによって検出されるかどうかを調べます:
$ lpinfo -V一般ユーザーの権限とルートの両方で、CUPS のパラレルポートバックエンドを単独で動かして見てください:
$ /usr/lib/cups/backend/parallel
$ sudo /usr/lib/cups/backend/parallel- バグレポートに上記のコマンドの出力を添付してください。
問題は CUPS だけで起こっているわけではなく、カーネル (パッケージ "linux")、HPLIP (パッケージ "hplip")、その他サードバーティ製プリンタードライバーでも起きうるということに注意してください。
CUPSウェブインターフェース
http://127.0.0.1:631/で、CUPSのWebインターフェイスは、いくつかの有用なメッセージと診断機能を提供します。
CUPSのerror_log
CUPSが何をしているかに関する情報を書き込むファイルです。印刷の問題のほぼすべてがエラーログから診断することができます。したがって問題を解決するために、まず最初に調べるべきものです。便利なようにするには、ロギングレベルを変更する必要があります:
Ubuntu Gutsy 以降のバージョンでは、デスクトップのメインメニューから「システム」->「管理」->「印刷」を、Oneiric以降のUnityデスクトップの場合は右上にある(ログアウトのときにも使われる)ギアのアイコンをクリックすると現れるメニューから「プリンター」をクリックします。プリンタ設定ツールであるsystem-config-printerが開きます。古いバージョンの場合、左側のリストから「サーバーの設定」を選び、プリンターがアイコンで表示されている新しいバージョンの場合は、メインメニューで「サーバー」を選んでから「設定」を選びます。Oneiric以降のUnityを使っている場合、メインメニューが画面の上部のバーにあることに注意してください。トップバーにマウスを動かしたときだけ表示されます。次に、チェックボックス「トラブルシュートのためのデバッグ情報を保存する」をチェックして、"適用"をクリックしてください。
すべてのUbuntuのフレーバー(Kubuntuおよびサーバー版も)は、
$ cupsctl LogLevel=Debug
を実行することでデバッグロギングをアクティブにすることができます。Karmic 以降(CUPS 1.4.x 以降)では、印刷ジョブが失敗した時にかぎり自動的にデバッグログを取る機能があります。そのため、もし印刷ジョブが失敗したなら、error_log には必要な情報がすでに含まれているかもしれません。しかし残念なことに、失敗したジョブごとに記録されるデバッグメッセージはわずか200行です。以下のコマンドを実行することで、事実上無制限の長さのログを印刷失敗時に残すことが出きるようになります。
$ cupsctl LogDebugHistory = 999999すべてのフレーバーについて、"cupsctl" コマンドが存在しない古いバージョンでは、/etc/cups/cupsd.confファイルをエディタで開き、 LogLevel ... の行を見つけて LogLevel debug としてファイルをセーブします。それから CUPS を再起動します:
$ sudo /etc/init.d/cupsys restart詰まってしまったジョブをキューから取り除くために、ジョブビューアーで削除するか、 "cancel -a" コマンドを実行します。
- 何かを印刷してみます。プリンターから何かが出力されるかどうかはおいておいて、印刷ジョブがキューから消えるか、それとも「停止」状態になるかまで待ちます。もしジョブが「停止」状態にも到達せず、プリンターが長時間なにも反応しないのであれば、そのまま次のステップに進んでください。
- もし印刷結果が正しくないならば、結果をスキャンするか写真に撮ってバグレポートに添付してください。
バグレポートに /var/log/cups/error_log} を添付します。このファイルは通常のユーザー権限ではアクセスできないことに注意してください。Jaunty 以降では、最初に作成したアカウント(より一般的には"adm"グループに属したユーザー)ならアクセスできます。それ以外の場合は、rootとしてアクセスする必要があります。ファイルを見るには<<BR>> {{{$ sudo less /var/log/cups/error_log
を実行し、ファイルをコピーしてバグレポートに添付するには
$ sudo cp /var/log/cups/error_log ~
$ sudo chmod 777 ~/error_log
を実行してください。
トラブルシューティングウィザード
system-config-printer (GNOME classicでは「システム」->「システムツール」->「印刷」、Unityでは画面右上のギヤアイコンから「プリンター」) には、トラブルシューティングウィザードが存在します。system-config-printerの「ヘルプ」メニューから起動できます。これにより、バグレポートに添付するための有用な情報をたくさん持つテキストファイルを生成できます。ウィザードの指示に従ってください。テストページを行うステップでは、ボタンをクリックしてテストページを印刷することも、適当なアプリケーションから選択されたプリンターに印刷することも、コマンドラインから印刷することもできます。ジョブは、統合されたジョブビューアに表示されます。ジョブが完了するか"停止"状態になるまで待ちます。「結果がはっきりと分かってから」ジョブをマークし、その印刷ジョブが正しく印刷されたかどうかを答え、「次へ」をクリックします。その後にファイルが生成されることになります。保存し、バグレポートに添付してください。
印刷エラーポップアップウィンドウ
印刷ジョブが失敗した場合、失敗したジョブ("停止"状態)があるジョブビューアーと、ジョブに問題があることを知らせるポップアップウィンドウが表示されます。"診断"ボタンをクリックすると、トラブルシューティングウィザードが開きます。ウィザードを完了する前にジョブを削除しないでください。問題が発生しているプリンタを選択してください。"テストページ"ステップでは、何か印刷したり、待機したりする必要はありません。統合されたジョブビューアで停止したジョブをマークし、質問に「いいえ」と答えてから「次へ」を押します。その後、ファイルを保存し、バグレポートに添付してください。
AppArmorによる印刷システムの保護
Gusty以降から、CUPS印刷システムのセキュリティはAppArmorの利用により改善されました。しかし残念ながら、特にサードパーティ製のプリンタードライバーを利用している場合、AppArmorの設定は完璧ではありません。あなたが印刷に関して問題がある場合は、sudo aa-complain cupsd のように AppArmorを無効化してください。これで問題が解決される場合、/var/log/messagesファイル内で audit が含まれているメッセージを探します。これによって /etc/apparmor.d/usr.sbin.cupsd で明示的に許可が与えられていないコンポーネントのうちどれが印刷システムからアクセスされているかが分かります。sudo aa-enfoce cupsd によって AppArmor を再度有効にできます。パッケージ cups (8.04 以前の場合は cupssys) についてバグレポートしていただければ、AppArmor の初期設定を正しくすることができます。
印刷ジョブのデータをキャプチャする
アプリケーションか印刷サブシステム、どちらに問題が起きたかをはっきりさせるため、プリンターに実際送られたものがなんであるかをはっきりさせることがしばしば必要になります。そのためには、アプリケーションから送られてくるデータをキャプチャし、それがすでに壊れているかどうかを調べるのがもっとも簡単です。そのためには、次の手順を実行します:
印刷キューをクリアし古いジョブを除去します。ジョブビューア上で行ってもよいですし、コマンド
$ cancel -a
を端末ウィンドウで実行してもよいです。問題が起きている印刷キューを無効にします。system-config-printer (GNOME Classicでは設定 -> システムツール -> 印刷、Unity ではスクリーンの右上にあるギアアイコン -> プリンター) を用い、対象のプリンターアイコンで右クリックし、ポップアップメニューの「有効」をクリックすれば、チェックマークが消えます。あるいはコマンド
$ cupsdisable <PRINTER>
を端末ウィンドウで実行してください (<PRINTER> はプリントキュー名に置き換えます)。この操作により、キャプチャーし終わるまでの間、ジョブをキューに溜めておくことができます。アプリケーションからジョブを印刷します。アプリケーションがジョブを送信し終わったなら、ジョブビューアかコマンド
$ lpstat -o
で、キューにジョブがあるかどうかを確認します。次のコマンドでCUPSのスプールディレクトリの中を確認します
$ sudo ls -1 /var/spool/cups
(必要に応じてパスワードを入力します)。"d" から始まるファイルがただ一つだけあるはずです。このファイルをホームディレクトリにコピーします:
$ sudo cp /var/spool/cups/d... ~/printout
$ sudo chmod 777 ~/printout印刷キューを再び有効にします:
$ cupsenable <PRINTER>
- もし印刷が正しくされてしまった場合、別のファイルを用いて同じ処理を行ってください。確実に問題が生じるファイルが必要なのです。
コマンド
$ file ~/printout
によってどのような形式のファイルか調べます。通常、PDFまたはPostScriptでしょう。ファイルを画面に表示してみて、問題が生じているか (エラーメッセージが出るとか、文字が欠けるとか、色がおかしいとか) 確認します。もし問題がある場合、容疑者はアプリケーションです。バグレポートをそのアプリケーションに割り当ててください。そうでない場合は cups パッケージに割り当てます。- バグレポートには、アプリケーションの元のファイルと ~/printout ファイルを添付してください。
既知のバグ
既知の問題、それらを認識する方法と、その応答とアクションを蓄積したものについて説明します。