職場のカラープリンタから印刷が出てこないとのSOSがあった。
問題のプリンタはネットワークに接続されていて、印刷用のサーバ経由で印刷するように設定してある。
このプリンタに時折データが送られなくなってしまって印刷が止まってしまう。
原因は大体がデータの容量が大き過ぎること。
プリンタが大きなデータを処理するのに時間がかかりすぎると印刷用サーバが次のデータを送らなくなってしまうようで、キューには溜っていてデーモンも動いているのだけど、実際にはプリンタ側にデータが送られていない状態になってしまう。
今回も1ページの印刷データが60MBを超えるものもあり、一番小さいデータでも30MB強。
こんなのを複数纏めて印刷要求されたらサーバも一個づつしかデータを送らなくなってしまうので、1つのデータが印刷完了するのを待ってサーバ側でデーモンの再起動を行うしか回復の手段が無い。
今回もプリンタの状態を監視しながらサーバ側の操作をしていたけど、なんとかならないものかなぁ？
つか、1ページ分の印刷データの容量が数十メガってどういうことだ？
More from: lpd
←クリックしてくれると嬉しいです。
ちょっとだけ前進か？
RISOのカラープリンタ（「ORPHIS X7250A」）へLinux機からの印刷が出来なくて悩んでいる。
最初はlpdを使ったサーバから印刷させようとして/etc/printcapをいろいろ弄っていたが、どうやってもプリンタ側へのデータの送信が出来なかった。
「もしかしてlprに対応していないのか？」とも思ったが、仕様上は対応していることになっている。
それでも上手くいかないので次にcupsで運用しているサーバでRAWポート（9100番ポート）にデータを送ってみたが、データは送られたように見えるが印刷が出ない（これはプリンタ側に無いユーザーで送ったためと思われる）。
数時間の格闘の末lpdで運用しているサーバからのデータ送信に成功した（と思われる）。
/etc/printcapにはリモートホスト名とリモートホスト上のプリンタ名を記述するが、そのプリンタ名が違っていることが判明。
「ORPHIS X7250A」上のプリンタ名は単なる「lp」らしく、/etc/printcapのrpにlpを指定したところ、それまでスプールに溜まっていたデータが無くなった（プリンタに送られたと思われる）。
それまで「lpt1」やら「pr1」やらのプリンタ名を試していたけど、まさかこんな単純な名前だっとわ（汗）。
気付いたきっかけはWindowsXP上の「Standard TCP/IPポート」の詳細設定で、プロトコルをRAWからLPRに変えてLPR設定のキュー名を「lp」にしたら印刷が出来たこと。
このことで「ORPHIS X7250A」が持つプリンタ名は「lp」だろうと見当がついた。
これでサーバからプリンタへのデータ送信に関しては解決したと思われるが、サーバ上に定義したプリンタに対してクライアントであるWindowsPCから印刷データを送ることが出来ない・・・・・・
現在の接続方法はLPTポート（LPT1とかLPT2）に対してnet useコマンドでLinuxサーバ上のプリンタを接続していて、プリンタの使用するポートとしてLPT1等を指定している。
同じサーバ上の他のプリンタに対してはこの方法で問題無く印刷データを送ることが出来ている（印刷できている）。
ところがサーバ上に定義したRISOのカラープリンタ（「ORPHIS X7250A」）を接続したポートにはデータを送ることが出来ない。
テストページの印刷を試すと印刷開始から即座に
「このドキュメントの印刷に失敗しました。」
のメッセージが出てスプールに残ったままになってしまう。
サーバ上のスプールディレクトリのアクセス権とかもチェックしたが他のプリンタとの違いは無い。
PCからサーバにデータを送ることが出来なければ印刷されるかどうかも解らないままだ。
この問題に間しては昨夕から一歩も進んでいないなぁ・・・・・・・
明日もまたこの問題で悩むことになりそうだけど、多少思いついたことがあるので、明日はそれらを試して見ることにしよう。
←クリックしてくれると嬉しいです。
指定したのとは別のプリンタから印刷される
先日仕事で行った先で、
「印刷なんですけど、たまに違うほうのプリンタから出るときがあるんですよ。」
と言われた。
問題の印刷はサーバー上のプログラムから出しているもので、ユーザーが操作するクライアントPC側では出力先のプリンタの指定をすることは出来ない。
しかもサーバ上での設定で違うプリンタを指定しているなら毎回違うほうのプリンタから出るはずなのだが、毎回ではなく”たまに”だということなので単純な設定ミスでは無い。
不思議なこともあるものだと思っていたら、思わぬところに原因があった。
件の印刷は本社のサーバ上で動作するプログラムが出力し、その際に出力先を現場に置いてある別のサーバに定義してあるプリンタを指定している。
この現場のサーバでのプリンタの定義に問題があった。
現場のサーバは古く、印刷システムがlpdなので、プリンタは/etc/printcapで定義している。
この定義の中にはプリンタのエントリが2台分あるのだが、スプールディレクトリの指定（sd=/var/spool/lpd/hogeの部分）が2台とも同じディレクトリになっていた。
仮に1台目をプリンタA、2台目をプリンタBとした場合、プリンタAに対して印刷要求を出した場合もプリンタBに出した場合も実際の印刷データは同じディレクトリに置かれることになる
このためプリンタAに対して印刷要求を出した際に、たまたまプリンタBに対応するデーモンが動作していると、プリンタAに出力する筈のデータもプリンタBに出力してしまい、データをプリンタBに送り終わるとデータを消去することになる。
しかもプリンタは直付けではなくプリンタサーバ経由での接続の為、データの転送はプリンタに直接送るよりも早く終わる。
このため本来印刷する筈のプリンタAではなく、もう一方のプリンタBで印刷されるということが起きてしまっていた。
いやぁ、最初は目的のプリンタにデータを送れない場合に自動で切り替えているのかと思ったが、そんな設定をした覚えはないし、lpdはそんな頭の良いことはしてくれない（爆）。
判明してみれば初歩的な設定のミスだったが、今後は気をつけないとなぁ。
←クリックしてくれると嬉しいです。
printcapの書き順で変わるのかな？
職場のプリンタを一台ネットワークプリンタに替えた。
今までLinuxサーバのパラレルポートに直結していたプリンタが不調になり、買い換えたプリンタがUSBとLANのポートしか持っていないので、仕方なくネットワークで接続することになった。
で、Linuxサーバ側のprintcapをリモートプリンタ対応に修正（問題なく印刷されているもう一台のプリンタ用の設定をコピーしてきて、リモートホスト名とスプールディレクトリ名を書き換えた）してlpdサービスを再起動したが、印刷がされない（あれ？）。
今まで他所ではこれで良かった筈なんだけど、今回は何故か素直に印刷されない。
lpc status lp
を実行してみるとスプールには溜まっていて、リモートホスト（この場合はプリンタのネットワークインターフェース）にデータを送信しているとなっているが、プリンタ側のjobランプは消灯したままなので、データは送られていない。
lpd restart lp
を実行すると印刷されたので、どうやらプリンタには異常は無さそうだ。
ここで再度印刷をしてみたが、やはりサーバのスプールに溜まるだけで一向にプリンタにデータが送られない。
しかも今回は
lpd restart lp
としても印刷されず、
/etc/rc.d/init.d/lpd restart
を実行してlpdサービスを再起動し、その後に
lpd restart lp
を実行してようやく印刷された。
うーん、何故？
結局のところ他所のサーバのprintcapの中身を参考にして行の順番を一部入れ替え、
/etc/rc.d/init.d/lpd restart
を実行したところ無事に印刷が出た。
数度印刷を繰り返しても素直に印刷されるので、原因はprintcapの記述にあったようだ。
必要な事項は全て記述しておいたのだが、行の並びも大事だったようだ。
でも、もう一台のプリンタは問題なく印刷されるんだよなぁ、、、、、、何故？
←クリックしてくれると嬉しいです。
lpdでプリンタに接続できない
linuxで運用しているサーバにプリンタを追加してlpdサービスを再起動したらネットワークプリンタに接続できなくなってしまった。
印刷にはlpdを使用しているので、/etc/printcapに新しいプリンタの定義を追加して、/etc/rc.d/init.d/lpd restartをして、/usr/sbin/lpc restart プリンタ名を実行したところ、
/usr/sbin/lpc: connect: Connection refused
couldn’t start daemon
となってしまいプリンタに印刷データを送れなくなってしまった。
追加したプリンタだけならまだしも、定義しているプリンタ全てに対して同様のメッセージが出て印刷できない。
このサーバは印刷の為だけに使っているサーバなのでrebootもしてみたが症状に変化は無かった。
何故なのか判らないので悩んでいたら、一部のプリンタから印刷が出始めたと連絡があり、その後順次復旧した。
以前にも同じ現象が他のサーバで発生したことがあり、その時はlpdプロセスが余分に動いていたので止めたところネットワークプリンタに接続できるようになったことを思い出した。
今回も同じだったのではないかと思うが、なにもしないで復旧したので確かなことは判らない。
次回は余分なlpdを止めることから始めてみよう。
←クリックしてくれると嬉しいです。
Linuxでプリンタのステータスが正しく表示されない（？）
Linux上で使われている印刷システムは現在CUPSが主流だと思うが、未だにlpdを使っているサーバが少なからずある。
印刷キューの状態は「lpc status ”プリンタ名”」で見ることが出来るが、ちょっと面白い現象に出くわした。
プリンタサーバ側にトラブルがあって複数のキューが溜まってしまったプリンタのステータスを見たら、
queuing is enabled
printing is enabled
21 entries in spool area
no daemon present
と出ていた。まぁこの表示自体には問題が無い（no daemon presentとなっているがプリンタサーバの応答が無いのでdaemonが止まっているため）。
止まっていたプリンタサーバを再起動し、lpc restart ”プリンタ名”で印刷を再開させてから再度ステータスを見ると、相変わらず「no daemon present」となっている。
ところがプリンタサーバ側にはデータが送られていて印刷が始まっている。
他の端末でステータスを見ると「sending to ”プリンタサーバ名”」となっていて正常に印刷データを送っていることになっている。
同じサーバの同じプリンタのステータスを見ているのに違う結果が表示されている。
不思議に思ったがこの違いは一般ユーザーで見ているかスーパーユーザーで見ているかというところにあった。
一般ユーザーで見ると「no daemon present」と表示され、スーパーユーザーで見ると「sending to ”プリンタサーバ名”」と正しく表示される。
/etc/printcapで指定するスプールディレクトリ（一般的には「/var/spool/lpd/”プリンタ名”/」）にあるstatusというファイルの内容もsending to ”プリンタサーバ名”となっていたが、一般ユーザーだときちんと読み取れなかったらしい。
パーミッションも644になっているので何故読み取れなかったは不明。こんなこともあるんだなぁ？
←クリックしてくれると嬉しいです。