今日は比較的好調

とは言っても、Skypeはいつの間にか死んだりしているのですが^^;
まぁそれでも、デスクトップが死ぬ訳でなし、ウィンドウマネージャが死ぬ訳でなし。比較的好調ですな。まだuptime4時間弱だけど(ぉ
しかし、今度はyumが不調。これは大学のマシンもそうだから環境依存とは限らないかもしれない。
なぜかselinux-policy-targetedパッケージをyumで更新すると、relabelの作業が止まっちゃうんだよなぁ。気になるのはrelabelのプロセスが2つ走っていること。デッドロックでも起こしてるんじゃなかろうか。素でrelabelプロセスを実行した事ないから本来2つプロセスが走るのかもしれないけど、なんか怪しい。
という訳で、大学のマシンはyumのupgradeプロセスを中断せざるを得ませんでした。おかげでupgradeは完了しましたがclear作業が実行されず。他のパッケージも巻き添えを喰った形になってしまいました。
今後はselinux-policy-targetedパッケージは個別にupgradeし、被害を最小限に食い止めるようにしよう。どうせSELinuxなんて使ってないから削除しようとしたら1300パッケージ依存性訴えられたから断念。難儀だ・・・。
しかし、ぼちぼちFedora8の情報も転がり出してもいいんだけどなぁ。インストールしてみましたは見つかるけど、やっぱ常用している人は少ないのかしら? やっぱ世の中Ubuntuか!Orz
ま、実際Fedoraにこだわる必要はないんだけどね^^; けどRPMに慣れすぎちゃったからなぁ。今更debでの管理を覚えられるか不安。逆に言えばそれくらいしか不安要素はないのだけれど(ぉ
うむむ・・・、/homeディレクトリは別パーティションだから移行は簡単。考えておこうかしらなぁ・・・。

広告

U.N.不調の原因はOSなのか?

グラボを抜いて、内蔵グラフィックチップでLinuxを動かしてみました。
その結果、Xが死ぬことはなかったのですが、やっぱり時間が経つとタスクトレイのアイコンが1つ、また1つと死んでいきます。大学のマシンはさしてプロセスを走らせていないので気付いていないだけなのか、はたまたやっぱうちの環境がよろしくないのかどっちなんだろう。
起動してから3時間程度はまぁ何も起きないことが多いんですが、それを過ぎたあたりからプロセスが死に始めます。大学の方も家と同じくらいごちゃごちゃと起動させてみるかなぁ・・・。
ただ、いくらなんでもkdesktopが死ぬのはおかしいと思うんだよねぇ。デスクトップの背景を表示するプロセスが死ぬって、普通考えられんでしょう^^;
この場合、悪いのはOSってことになっちゃうのかなぁ? Windowsは問題なく動作してるし。
ふぅむ。けど大学のマシンは長時間付けっぱなしでもkdesktopが死んだなんてことなかったしなぁ。
それにFedoraも長らくアップグレードアップグレードで続けてきたのを思い切ってやめて、7で、しかも64bit版を新規で入れたからなぁ。7から8はアップグレードだけど、にしても不安定だったから、これは家の環境だろうとか思ったんだけど・・・。
う〜んむ。Linuxさえ快適に動いてくれれば文句のないマシン構成なんだけどなぁ。まぁメモリは増設したらいいし。2GBが上限なのが玉に瑕ではあるけど。
金が出来たらマザー買い換えるかなぁ。Winが多少不安定でも文句はなかったのに(ぉ
問題は、マザボを交換しても改善するとは限らないところか。こればっかりは分からないもんなぁ。ほんと、なんだろか原因。プロセスが堕ちた直後にdmesgとかsyslog、Xのログとか確認したけどどれも異常なし。というか情報無し。
なんか痕跡のひとかけらでもあればそっから手がかりが見つかるかもしれないんだけどねぇ。今の状態では調べるにも絞り切れてない状態。
ほんと、どうにかしてくれぃ><

PulseAudioがクラッシュしたときの復帰法

Fedora8で採用されたPulseAudioですが、まだまだ不安定です^^; しょっちゅう堕ちます。
で、プロセスごと堕ちてくれたら
$ pulseaudio -D
でデーモンを再度起動すれば済む訳なんですが、たまにデバイスの扱いに失敗するのか、デーモンは起動しているけれどデバイスを認識できない状況に陥ります。
状況として、
・いきなり音が鳴らなくなった
・PulseAudioManager(pam)でステータスを確認すると、サーバには接続しているが各情報がすべて n/a
となっていたら、プロセスが起動したままクラッシュしています。この場合、
$ pulseaudio -k
としてもデーモンプロセスが死にません。
解決法は、/tmp/pulse-`whoami`/pidファイルに書かれているプロセス番号のプロセスを強制KILLです。具体的には、
$ kill -KILL 1234
です。1234は上記のファイル内の数字に置き換えてください。うまくプロセスを殺せたら、
$ pulseaudio -D
でデーモンを起動させて復帰です。
しかし、まさかpsコマンドで見えるプロセス名が「exe」とは思いませんでした。以前から
「なんでwineも動かしてないのにexeなんてプロセスが走ってるんだろう・・・?」
と疑問には思っていたんですよね。で、試しに
$ ps auwx | grep 18936 #18936はexeのプロセス番号
で確認したところ、

tako 18936 8.9 0.7 220972 5828 ? Ssl 13:37 3:40 pulseaudio -D

ってなってました。なんで「exe」なんて表記にしてんだろ・・・?
今でも時々PulseAudioがおかしくなりますが、だいぶ扱いが分かってきた気がします。以前にもこれと同じ状況に陥り、その時はどれがpulseaudioのプロセスか分からなかったので再ログインしたんですよねぇ。これでだいぶ対処がマシになりました。
以前より遅延も見られなくなったし、もうちょっとってところかな。プロセスがずっとデバイスを握りつづけてたら安定してるんだけど、デバイスを解放したり確保したり〜と頻繁に繰り返すとついていけなくなるって感じですね。
特に、aRtsとの相性がよろしくない。akodeplayが引数なしでpulseaudioを利用してくれるんならそれで片付くんだけどなぁ。aRtsは時代遅れだから使いたくないよ^^;
でもアップグレード直後に比べたらはるかに安定してるので、このまま使いつづけてみますかね。プロセスごとのボリューム調整は結構面白いし。記憶してくれないのが難点だけど。記憶させる方法もありそうだけどなぁ。
ま、ぼちぼち調べていきますか。Fedora8はまだ情報が少ないし。けど私のBlogはあんまり検索上位には入っていかないんだよなぁ。未だにエキブロのBlogの方が上位だし^^;
もちっと有用な情報出していかないと上位は難しい!?

デスクトップをみっくみくにしてみた

まぁ表題の通りであります。ちょっくら遊んでみました。ほんとはもうちょっと細かいディティールにもこだわりたかったんですがねぇ(苦笑
事の発端は、Velnirとのチャットだったり。ApricotってなWinのペルソナウェアではちゅねミクを動かしてる動画があって、それを送りつけたら「てめ〜もやれよ」とのご託宣を受けまして。
で、やろうとした(Linuxで)んですが、まぁ動くわけもなく。
最初Wineで動くかな〜ってチャレンジしたんですよ。そしたらなんと
「このバイナリは.NETだからMonoで動かせやゴルァ!」
って怒られまして。Apricotの配布サイトにはなるほど確かに.NETが必要と書いてあります。
えぇ、ダメだろうと、ダメだろうと思いましたよ?でもやらんわけにはいかん!ということで、monoで試してみました。
見事撃沈(ぉ 他にもSSPの初音ミクとかもあったんですが、ninix-ayaをビルドできなかったので断念。32bit環境ならできたかもなぁ。ターゲットアーキテクチャの変更ってできないんだろか? できるとは思うけどちょっくら分からなかったなぁ。
ということで、壁紙とスカイドームくらいしか設定できませんでした。Superkarambaのウィジェットはそのうち作ろう。
それよか先に、Linuxが安定動作するハードウェア環境を構築しないとね^^;

Fedora8にしてよかったこと、わるかったこと

相変わらず今日もXが堕ちまくる。ほんと、これの原因は特定したいなぁ。いい加減にしてくれよと。
さてさて、表題の通り、よかったことと悪かったことを考えてみましょう。
○よかったこと
・Compizがなかなかクール。BerylのときはF8キーがショートカットキーとして喰われてたけど、Compiz-fusionになってその設定がなくなったようなので半角カナを打てるようになって幸せ(ぇ
・64bitのみでよくなったパッケージが増えた。Flashもラッパーを噛ませることで64bit版Firefoxで動作可能。こいつはなかなか嬉しいお話。32bit版Firefoxを卒業しますた。
・IcedTeaが意外と使えること。JavaはJREの更新が割と頻繁で鬱陶しい。IcedTeaでAzureusが動いたので当面はこれで問題無し。Eclipse+CDTも動作するし、特別IcedTeaで問題ないかな。
◇わるかったこと
・PulseAudioに変更されたこと。別にALSAのdmixで困ってなかったのに、PulseAudioに強制変更されたおかげで設定をやり直す必要が多量に出てきた。デバイス問題にも悩まされたし、akodeplayコマンドがデフォルトでpolypを使用しないためaRtsを復活させる羽目になった。こいつがかなり不安定なので困っている。
・Skypeが使えなくなった。PulseAudioに対応していないため。ALSA経由とかだと使えたんだけど、ALSAデバイスを直接叩くためPulseAudioをサスペンドさせてSkypeを使うしかない。当然、その間はPulseAudio経由での音はでない。
・beagled-helperプロセスが大暴走。これはFedora8のせいじゃないかも。けどCPUリソースを90%近く持っていくのはやめてほしい。おかげでクロックが2GHzから下がってくれない。killすら無視するこいつはいったい何なの!?
ざっと思いつくのはこんなところかな。いいところとわるいところ、それぞれで相殺する感じだろうか? PulseAudioは悪い方に入れたけど、これは時間が経てば洗練されていくだろうから、いい方に入っていくと思われる。aRtsもESD経由で動作させたら安定に動作するみたい。ESDもaRtsも更新が止まって久しいものなあ。不安定だったのはALSA経由にしていたからみたい。そーいやaRtsってALSA経由だと不安定だったっけ・・・。
にしても、なんでakodeplayのデフォルトsinkもpolypにしなかったんだろう。そうしてくれてたらaRtsを起動する必要なかったんだがなぁ。システム通知をakodeplayにさせてたからなぁ。便利でよかったのに。これ以外に多数のフォーマットに対応した軽いコマンドって思いつかないのよなぁ。mplayerにさせるのは大仰な気がするし。
う〜んむ、akodeplay以外に、wavとoggに対応したコマンドラインベースのサウンドプレイヤーないかしら。aRtsはなんか好きになれないのよねぇ(苦笑)
ま、それよりなによりXが死ぬ原因を突き止めたいもんだ。こっちの方が深刻なんだよなぁ。大学のマシンは安定して動いてるから、ハード面だと思われます。だから余計に困ってるんだよなぁ・・・。
新マシン構築するにも金がない。はぁ、ハズレのハード構成だったなぁ・・・^^;

なんだこのむらは

今日はXが4回ほどお亡くなりになりました。何なんだ一体?
ふと、この不調はオンボードグラフィックをBIOSで無効にするのを忘れいてたからだろうかと思い、確認してみました。するときちんとBIOSで無効化していました。
う〜んむ、やっぱ相性・・・?
この不調がグラボのせいなのかM/Bのせいなのかははっきりさせたい所存。グラボとCompizの相性ということは考え憎いので、まぁこのM/Bとグラボの組み合わせがよろしくないということなのでしょうが・・・、この場合取れる選択肢は2つほど。
1つはグラボを交換する方法。1万円くらいで済みますかね。いっそのことオンボードグラフィックにするという手もあります。さして性能を欲していない今、オンボードグラフィックでも特に問題なく動きそうな気もします。
2つはM/Bを交換する方法。こちらも1万円くらいで済みます。換装の作業は面倒ですね。一旦全部外す必要がありますし。Linuxの方は交換後rescueディスクで起動してinitrdを再構築する必要あり。Windowsは下手すると入れ直しだなぁ。修復インストールで何とかなるとは思うのだけれど。もし再インストールならVista64bitだな(ぉ
しかし、今日も再起動した今の状態はすこぶる安定。一体何が不安定にさせているんだか・・・。
ところで、家のFedoraではUSBメモリが自動マウントできない状態となっております。なんかHALが文句たれるんですよねぇ。現れるメッセージでぐぐっても64bit版のopenSUSEしか引っかからないし。Fedoraでは出ていない症状なんだろうか?
SUSEの方では安定に動作していたときのパッケージをインストールしなおすことで回避してました。Fedoraもそうしたいところですが、F8の時点で既に発生している不具合なのでこれ以上戻しようがなかったり。F7のときにはマウントできていましたが、64bit以降どのタイミングでマウントできなくなったのか確認していないためどのverが安定に動作するか分からないんですよねぇ・・・。何気に不便だからどうにかしたいや。
にしても、Fedora8の情報はほっとんど出回ってないなぁ。検索の仕方は悪いかもしれないけど。そのうち色々と見つかるかなぁ? online-desktopとか面白そうだから知りたいのに。
やっぱここは人柱しかないか!? ま、色々試してみますかね^^

サウンドデバイスの権限問題解決法

先日ポストしたPulseAudioはなかなかよいかも知れないの記事に、/dev/snd/*等のデバイスの権限を強引に0777に置き換える方法を紹介しました。
するとjacopassさんがコメントにて解決法を紹介してくださいましたのでそちらを紹介します。この記事にてお礼とさせていただきます。
まず、/etc/security/console.perms.d/51-audio.permsというファイルを作成します。jacopassさんは50-default.permsファイルを編集する方法を紹介くださいましたが、こちらのファイルは手動で編集すべきファイルではないということで新規にファイルを作成することとします。ファイル名は先頭の数字が50より大きければ以降は任意です。ただし、拡張子は.permsにしてください。
編集する内容はコメントにいただいた通りです。以下の内容を保存してください。

<sound>=/dev/dsp* /dev/snd/* /dev/mixer
# permission definitions
<console> 0666 <sound> root

以上で完了です。先日の私の記事で書き換えた箇所を元に戻し、再起動すればOK。
記述の意味ですが、まず1行めはデバイスをグループ化しています。右側に書かれたデバイスはきちんと存在していなければなりません。
次の行は単なるコメントです。
最後の行がパーミッションに関わる内容で、<console>はコンソールからのログイン、ようはローカルからのログインを示します。
次のセクションでパーミッションを指定します。ログイン後、各ユーザにここで指定した権限が付与されます。
次のセクションがデバイスグループの指定です。先ほど作成したグループの<sound>を指定しています。
そして最後のセクションは、ユーザがログインした後にどのユーザに権限を戻すかを示しています。ここではrootユーザに戻しています。
一般にサウンドやビデオデバイスはこの方法かあるいは先日紹介した方法でパーミッションの設定を行わないといけません。その場でデバイスのパーミッションを変更しても、再起動すると元に戻ってしまいます。
そういえばKVMデバイスも元に戻っちゃってたな・・・。アレも同じように設定したらいいのか。
先日の方法と違い、今回の手法ではデバイスごとに個別に設定を行えるのでパッケージ更新などでファイルが書き換えられてしまう心配がほぼありません。逆に言えばその設定が不要になったときはちゃんと自分で消さないといけないということですが^^;
何はともあれ解決法が見つかってなにより。これでおおよそはうまく動いてくれるかな〜?