canonさん。

アドバイスありがとうございます。10.04はクリーンインストールです。

まず現在の状況を整理すると、

9.10-i386 → サービスは全て起動している。
10.04-amd64 → 同上
10.04-i386 → 一部サービスが起動してない。（bluetooth,cups,tuncfg)ただし、5回に1回位の割合で正常起動する。

上記起動するサービスについて確認しているのはbluetooth、印刷、hamachi-P2Pクライアント等、通常自分が使用するサービスのみです。

9.10-i386と10.04-i386は同じPCでHDDを入れ替えてますのでハードの故障ではないようです。

実は上記の不具合はβ2→RC（これもクリーンインストール）にしたときに起きるようになりました。RCで2回、正式リリース版で2回インストールしなおしましたが同じ状況です。

10.04は非常に動作が軽くて気に入っているので現状不便ですがもう少し使ってみて様子を見てみようかと思います。まれに正常に起動することもあるのでそのうち治るかもしれませんし。

hmatsueさん。

アドバイスありがとうございます。

$ grep cupsd /var/log/* | less の結果です。

/var/log/dpkg.log:2010-04-29 12:19:57 install libcupsdriver1 <none> 1.4.3-1
/var/log/dpkg.log:2010-04-29 12:19:57 status half-installed libcupsdriver1 1.4.3-1
/var/log/dpkg.log:2010-04-29 12:19:57 status unpacked libcupsdriver1 1.4.3-1
/var/log/dpkg.log:2010-04-29 12:19:57 status unpacked libcupsdriver1 1.4.3-1
/var/log/dpkg.log:2010-04-29 12:25:35 configure libcupsdriver1 1.4.3-1 1.4.3-1
/var/log/dpkg.log:2010-04-29 12:25:35 status unpacked libcupsdriver1 1.4.3-1
/var/log/dpkg.log:2010-04-29 12:25:35 status half-configured libcupsdriver1 1.4.3-1
/var/log/dpkg.log:2010-04-29 12:25:35 status installed libcupsdriver1 1.4.3-1
/var/log/kern.log.1:May  1 19:21:43 yota-laptop kernel: [ 1997.436265] type=1505 audit(1272709303.454:23):  operation="profile_replace" pid=5621 name="/usr/sbin/cupsd"
/var/log/messages.1:May  1 19:21:43 yota-laptop kernel: [ 1997.436265] type=1505 audit(1272709303.454:23):  operation="profile_replace" pid=5621 name="/usr/sbin/cupsd"

hmatsueさん。

エラーメッセージらしきものは特にでていないようですね。

そうなんですかあ。。私には $ grep cupsd /var/log/* | less の内容は理解できていないのですが、残念ながら実際に印刷はできません。
システム>システム管理>印刷 で管理画面を開くと左下のステータスは『接続されていません』となっています。正常だったら『localhostに接続』ですよね。
現状は印刷のたびに $ sudo service cups start と端末で入力している状態です。

しかし先に書きましたように稀に正常起動しているのでなんだかなあ、という感じです。

canonです。

sumiyota による投稿:

hmatsueさん。そうなんですかあ。。私には $ grep cupsd /var/log/* | less の内容は理解できていないのですが、残念ながら実際に印刷はできません。
システム>システム管理>印刷 で管理画面を開くと左下のステータスは『接続されていません』となっています。正常だったら『localhostに接続』ですよね。
現状は印刷のたびに $ sudo service cups start と端末で入力している状態です。しかし先に書きましたように稀に正常起動しているのでなんだかなあ、という感じです。

まだ「/etc/init.d/cups status」の結果や「ps」コマンドの結果が分からないのでまだ何とも言えませんが、念のため。

sumiyotaさんの貼り付けたログの内容を見るかぎり、下２行はapparmorのイベントログ、上がdpkg関連のログだとも思われます。なので、hmatsueのおっしゃられるとおり、これらのログは「エラーメッセージ」ではないような気がします。

#apparmorのログについては、時々ソフトが思うように動作しなかったり、デーモンが起動不能に陥ったりしとたときにでることがあります。firefoxのapparmorプロファイルを有効にしているときなども結構でますし「/etc/init.d/apparmor reload」したときは必ず出ます。firefoxのapparmorプロファイルはデフォルトで無効です。

あと

$ grep cupsd /var/log/* | less

ではなく

$ grep cups /var/log/* | less

とするとどうなるでしょうか。

補足として、grepの代わりにegrepを使って確認するのもよいかもしれません。これを使うときは

egrep -i cups /var/log/* |less

のようにすれば、検索する語の大文字・小文字の区別無しに検索することができますし、正規表現も使えます。

それとcupsのログ（「/var/log/cups」以下のディレクトリにあるログ）は見ましたか。（確認済であるならばごめんなさい）ログの文の最初の「W」や「E」の項目（Eから始まるログやWから始まる文。例えば「E  hogehohe～」「W  hogehohe～」のように。）中心に探すと、なにか解決法が見出せるのかもしれません。説明が分かりにくくてすいません。

cupsが起動したときには、cupsのログに何かを残していますから。

例えば

 egrep -i ^W /var/log/cups/error_log
 egrep -i ^E /var/log/cups/error_log

とすると、文頭が「W」「E」の文を絞り出せます。

ちなみに詳細なログをとるには「/etc/cups/cupsd.conf」の「LogLevel」を、

LogLevel debug

にして、cupsをリスタートさせると、cupsの詳細なログをとれます。

ログについては以下のURLも参考になります。英文ですが……・。

http://www.cups.org/documentation.php/d … r_log.html

参考までに。

daemonが起動していないのは確実のようですね。
なぜその理由がログにでていないのか謎ですが。。

sumiyota による投稿:

$ grep cups /var/log/* | less の結果はすごい文字量なのですがやはり貼り付けたほうがよろしいでしょうか？

あまりに多いようであれば、まずは、
$ grep -i cups /var/log/* | grep "May\s*6"
を投稿してみて下さい。
最後の部分の"May\s*6"は5月(Ｍａｙ）の6日を表します。
Ubuntuを起動して、cupsdが走っていないことを確認して、その日の日付に合わせて数字を変えて下さい。
例えば、5月7日なら、
"May\s*7"
となります。

みなさま、たびたびのアドバイスありがとうございます。

$ grep -i cups /var/log/* | grep "May\s*7" の結果です。

/var/log/auth.log:May  7 04:48:47 yota-laptop sudo:     yota : TTY=pts/0 ; PWD=/home/yota ; USER=root ; COMMAND=/bin/grep -i cups /var/log/ConsoleKit /var/log/Xorg.0.log /var/log/Xorg.0.log.old /var/log/apparmor /var/log/apt /var/log/auth.log /var/log/boot /var/log/boot.log /var/log/bootstrap.log /var/log/btmp /var/log/cups /var/log/daemon.log /var/log/debug /var/log/dist-upgrade /var/log/dmesg /var/log/dmesg.0 /var/log/dmesg.1.gz /var/log/dmesg.2.gz /var/log/dmesg.3.gz /var/log/dmesg.4.gz /var/log/dpkg.log /var/log/faillog /var/log/fontconfig.log /var/log/fsck /var/log/gdm /var/log/installer /var/log/jockey.log /var/log/jockey.log.1 /var/log/kern.log /var/log/lastlog /var/log/lpr.log /var/log/mail.err /var/log/mail.info /var/log/mail.log /var/log/mail.warn /var/log/messages /var/log/news /var/log/pm-powersave.log /var/log/pycentral.log /var/log/samba /var/log/speech-dispatcher /var/log/syslog /var/log/syslog.1 /var/log/udev /var/log/ufw.log /var/log/unattended-upgrades /var/log/user.log /var/log/

canonさん。やっぱり同じような症状の人がいたんですね～。私もそこそこいろんなトラブルに遭遇しましたが、今回のように再現率が100%ではない症状は初めてでしたので不思議です。

素人の勝手な想像ですが設定的には正常に起動するはずなので実際に起動していなくてもエラーがでないのでしょうか？

canonです。

hmatsue による投稿:

現状は手動起動して当面しのぎ、バグが修正されるのを待つしかないかもしれません。
バグが修正されたときに問題を起こす可能性がなくもないので、ちょっとどうかと思いますが、/etc/rc.localあたりにcupsを起動するコマンドを書いておけば少しだけ不便が解消されるかも。。

そうですね。serviceコマンドで起動するのでしたら「/etc/rc.local」にとりあえず書いておくとよいかもしれません。但しアップデート後はしっかり消しておかないと、新たな問題が発生するかもしれません。pidファイルの有無で起動しているかしていないか判別しているのであれば、たぶん二重に起動はしないと思いますけど……。

やったことないのでそこのほうはよく分かりませんが。

ちなみに「$ grep -i cups /var/log/* | grep "May\s*7"」のログですが、ログの内容はsudoのログですね。

#sudoを実行したら「/var/log/auth.log」にログが書き込まれるのです。sudoの場合、その「sudo」で行ったコマンドまでログられるので、SUよりとても便利ですよ。まぁ、ubuntuは原則ルート（root）がロックされていますから、SUは使えませんけど。

なんだかよくわからないけどCUPSを入れ直したら直った、という投稿もあるようですね。当面はrc.localあたりに設定しておくのが簡単ですが。。