気がついたら時代に取り残されていた

Fedora IgnoreLid

Fedora 19で「液晶パネル(LID)を閉じたらスリープする」動作を抑止しようとしたら、仕様が変わってて困ったので、健忘禄代わりに、設定方法を記載しておきます。設定方法が知りたい人は、一番下を見てください。


ちょっと休みのうちに複数サーバ環境の検証を…っと思って、今使っているFedora 19のクローンをゴリゴリ作り、ノートPCで起動。えっ?!なんでFedora? しかも仮想ではなく物理環境? うーん、昔は別のディストリビューション使ってたんだけどね、会社がRHEL使う様になったからFedora(Fedora Core)に移行して、後はズルズルとって感じですよ? あとなんで物理マシンを使っているのかは、主にメモリの問題…何ともアナログな…
で、ちょっと新しめのノートを心配したが、取りあえず問題なく起動完了。無線LANも認識したので個別修正…。仮サーバ共は邪魔なので液晶を閉じ、転がしておく。
クライアント側の設定をチョロチョロ弄り接続…ありゃサーバ共が応答しない??
よく見たら電源ランプが点滅しているよ〜そういえば、今のLinuxで液晶閉じるとスリープに入るの忘れてた。

/etc/UPower/UPower.conf

IgnoreLid=false

のfalseをtrueに変えて、/usr/libexec/upowerdを再起動…

# upower -d
…省略…
  lid-is-present:  no
…省略…

今度こそ準備完了。おりゃ!リトライ!っておい!!また止まってるぞ??えーなんで?

確かFedora 15のあたりは問題なかった様な気がするのだが??
…本来やるはずの検証を外れ、別の検証を始める…

Fedora 15

  • kernel-PAE-2.6.38.6-26.rc1.fc15
  • upower-0.9.10-1.fc15

fc15の初期構成。「IgnoreLid=true」に変えればスリープせず。

  • kernel-PAE-2.6.43.8-1.fc15
  • upower-0.9.12-1.fc15

fc15の最終リリース。「IgnoreLid=true」に変えればスリープせず。

Fedora 17

  • kernel-PAE-3.3.4-5.fc17
  • upower-0.9.16-1.fc17

fc17の初期構成。「IgnoreLid=true」に変えればスリープせず。

  • kernel-PAE-3.9.10-100.fc17
  • upower-0.9.19-1.fc17

fc17の最終リリース。「IgnoreLid=true」に変えればスリープせず。

Fedora 18

  • kernel-PAE-3.6.10-4.fc18
  • upower-0.9.18-2.fc18

fc18の初期構成。「IgnoreLid=true」に変えても、スリープしない環境とする環境がある。スリープしない環境でもスリープするときもある。かなり不安定。

  • kernel-PAE-3.6.10-4.fc18
  • upower-0.9.19-1.fc18

取りあえずupowerだけfc18の最終リリースに上げてみる。現象変わらず不安定なまま。

  • kernel-PAE-3.10.14-100.fc18
  • upower-0.9.19-1.fc18

カーネルもfc18の最終リリースに上げてみる。「IgnoreLid=true」に変えてもスリープしてしまう。前カーネルでスリープしない環境で実施してもスリープしてしまい、何度か試したが「スリープしない」現象を確認できず。つまり、Fedora 19の状態。

検証結果まとめ

  • Fedora 17までは、/etc/UPower/UPower.confで「IgnoreLid=true」を指定すれば、液晶パネルを閉じてもスリープすることはない。
  • Fedora 18からは、/etc/UPower/UPower.confで「IgnoreLid=true」を指定しても、液晶パネルを閉じるとスリープしてしまう。また、upower -dで設定を確認すると、Fedora 17以前と変わらず「lid-is-present: no」と認識されているが、動作と矛盾する。

追加調査

upowerdが言うことを聞かないので、killすることに決定。少なくとも、電源ボタン/スリープボタン操作が効かなくても、現状困ることはないし。で、液晶パタン…うをい、またか。どうやら、upowerdが言うことを聞かないのではなく、upowerdに関係なくupowerdのやっていたことを代行している奴がいるらしい。
dmesgを眺めていたところ、奇妙な行を発見。

systemd-logind[470]: Watching system buttons on /dev/input/event0 (Lid Switch)

LIDスイッチを見てるsystemd-logindとかいう奴がおるの? psで確認すると確かに動いているし。
で、こいつ何? と言う訳で systemd-logind → logind.conf とマニュアルを辿っていくと、(他に分担している作業もあるが)upowerdのH/Wボタン監視の上位モデルらしい。肝心の液晶パネルのスイッチ(LIDスイッチ)は…HandleLidSwitchで、設定可能値は、ignore, poweroff, reboot, halt, kexec, suspend, hibernate, hybrid-sleep, lockの9種類があるらしい(デフォルトがsuspend)。画面ロックされても面倒なだけだし、ここは何もするなのignoreかね。と言う訳で、logind.confを弄る。

/etc/systemd/logind.conf

#HandleLidSwitch=suspend
↓
HandleLidSwitch=ignore

killして再起動しても問題ない気もするが一応サービスプログラムらしいので、systemctlコマンドを使う。

# systemctl restart systemd-logind

今度こそ…液晶パタン…おぉ〜スリープしない〜クライアントからもアクセスできるよ。念のため、upowerdの設定をfalseに戻しても、upowerdが干渉してこないことを確認。

結論

Fedoraで液晶パネルを閉じてもスリープさせないためには…

  • Fedora 17までは、/etc/UPower/UPower.confのIgnoreLidにtrueを設定する。
    • 確かLIDスイッチの監視が実装されたときはIgnoreLidは用意されておらず、後から増えた設定値なので、この隙間に入ると多分駄目。
  • Fedora 18は、/etc/systemd/logind.confのHandleLidSwitchのコメントを外し、ignore等を指定する。さらに念のため、/etc/UPower/UPower.confのIgnoreLidにtrueを設定する。
  • Fedora 19は、/etc/systemd/logind.confのHandleLidSwitchのコメントを外し、ignore等を指定する。
    • Fedora 19の初期リリース状態で試してしないので、これで駄目だったらUPower.confの方も修正して。

ん？USBメモリって熱暴走するのか？？

PCパーツ

もう少しで夏休みも終わりですね。私は夏休みの日記が非常に苦手(毎日書くネタなんてないんじゃボケェ)でしたが、今もあるんですかねアレ？この夏は久々に毎日暑かったのがきつかった〜もう年だなぁと思ったり。日記なんて書いてたら、毎日ただ暑いと書いて怒られていただろうな多分*1。あと、2chが別の意味で熱くなっていますが、どう決着が着く*2んでしょうね〜。
熱い繋がりで、しょうもない話でお茶を濁…ゲフンゲフン…


使い切っている訳でも、用途に応じて使い分けている訳でもないのに無駄にゴロゴロ持っているUSBメモリの内、某社製超小型USBメモリなんだが、最近とっても調子がよろしくない。USBポートに差した直後は問題ないのだが、30分〜1時間ぐらいすると突然アクセス出来なくなる…デバイスとしては認識されているので、Read/Writeが出来ない状態(パーティションが認識できない)に陥っているものと推測される。
某社のメンツのために断りを入れておくが…同じモデル・容量のものを当該のものを含め3個持っている。問題が起きているのはその内のひとつで、残りのものはまったく問題なく使えている…たぶん製品の品質が悪いという訳ではない。だがしかし、「USBメモリ 熱暴走」でググったときに、おそらく同じものをカーエアコンへ突き刺している写真を発見したのは、気のせいに違いない…
話を戻すが、かなり奇妙な壊れ方をしている。

  • 少しの間は使用できるのでドライバやドライブレターの問題ではない
  • メンテナンス用に使用しているだけなので、普段はまったく使用していない＆使用頻度もかなり低い
      ⇒半導体的には寿命を迎えていないハズ
  • 一度現象が発生すると別のポート、別のPCに接続してしても、同様の症状になる
      ⇒上記条件も合わせるとUSBポート、USBメモリのUSB端子が摩耗している可能性は低いハズ
  • USBメモリを抜いて5〜6時間放置してから差すと、また使える様になる(まれに症状が継続している時もあるが…)。でも30分〜1時間すると発病する
  • なぜかUSBポートに付けたままだと復活しない
      ⇒PC停止時にUSBへの給電を止めているハズなのだが？微電が流れているのだろうか？

某SSDに対して、一度に大量書き込みを行うと、内部処理だけで手一杯になり、PCからの要求に応答できずSSDが認識されなくなるという現象があるが、あれは通電していれば回復する*3ので、この症状とは真逆。状況からすると昔のノートPCに良くあった熱暴走に良く似ている(どこぞの3文字 米メーカーのものは基板が溶けて復活しなかったが*4 )。しかし、CPU/GPU、チップセットやメモリなんかと違って高クロックで動作しているものではないのに熱暴走ってあるのだろうか…でも、復活するので見た目、熱暴走なんだよなぁ〜まぁいずれにしても別の器にしないと、危なくて使えたものではないのだが。

*1:8月の更新がない言い訳じゃないぞ

*2:ん？ただでさえ前々から「てにをは」がおかしいのに、文法までおかしくなってきたぞ…エセ日本人化しているのか??

*3:異常に時間が掛かるので、あれはあれで良いのか？って思わなくはないのだが…

*4:あれは修理に出しても、また溶けたし。同じものを使っている人からも同じ症状を聞いたから、リコールにしろと言いたかったな

MSYS環境下でのシステムコールトレーサー？(strace)の使い方

MSYS

Linuxのそれと微妙に使い方が違うので健忘録です。ヘルプも表示されないので…。
まず、トレースを仕掛けたい実行ファイルがMSYS DLLを使用していることが、strace実行の絶対条件です。具体的には、『「objdump -x 実行ファイル | grep DLL」を実行したとき、「msys-1.0.dll」が表示されること』です。
次に、MSYS DLLがデバッグ用のものになっている必要があります。こちらは、strace実行前に「msys-1.0-debug.dll」を「msys-1.0.dll」へコピーするだけです。
以上の2点の条件が揃わないと、straceを仕掛けても何も得られません。
なお、「msys-1.0-debug.dll」は、オリジナルの「msys-1.0.dll」と比べると、実行性能が非常に劣化するので、通常運用時はオリジナルに戻す必要があります。つまり、コピーする前にオリジナルの「msys-1.0.dll」をバックアップしておく必要があります。また、Linux環境のそれと同様に、「msys-1.0-debug.dll」+トレース実行環境では、処理がシリアライズされるため、問題の現象をうまく捉えられないおそれがあります。ただ一番の問題は、MSYSのstraceはシステムコールトレーサーではなく、MSYS DLLのデバッガツールであることを意識して使わないとならない事です。

続きを読む

パラレルmakeがハングするMSYS DLL v1.0.18を修正する

MinGW MSYS

昨日予告したMSYS DLL v1.0.18 修正版の作成方法を公開します。
作成されるMSYS DLLは、勝手にファイルバージョン 1000.18.0.1、製品バージョン 1.0.18.0.1を採番しています(オリジナルは、それぞれ1000.18.0.0と1.0.18)。また、今回のバグとは直接関係はありませんが、オリジナルのビルダーを使用すると、DLLのプロパティ情報が文字化けしていたので、こちらも修正しています。

その他

firestorageに格納したファイルへの直リンが、永続的なものではないことが分かり、バッチシェルの修正に時間を取られすぎた…。かなり、怪しい修正だが、取りあえず動いている様なので、暫くはこれで様子見。動かなくなったらゴメン。

続きを読む

パラレルmakeがハングする理由を調べてみる…再起動-バグ発見-

MinGW MSYS

ようやく捕まえました根本原因。やはりバグはMSYS DLLにありました。
MSYSが動作している環境をMSYS DLL v1.0.17(先日はv1.17、v1.18と書いていましたが、v1.0.17、v1.0.18の方が正しいVer表記です orz)では、「非NT系OS or NT系OS」、「64bit or 32bit環境」ぐらいのざっくりとしたレベルで管理していましたが、MSYS DLL v1.0.18では「Win95相当、Win98相当、…、WinXP相当、Win7相当」、「64bit or 32bit環境」のように細かいレベルで管理するようになりました。さらに、この管理部分では、動作環境がサポートしている機能の概略も保持するように、エンハンスが行われています。この機能概略の部分で新規に「pipeの処理中に割り込み処理を行っても良いかどうかの元となる情報」が用意されたのですが、なにを勘違いしたのか、最終的に結果を求めたとき、真逆の応答をしています。

続きを読む

パラレルmakeがハングする理由を調べてみる…再起動-2歩下がって3歩進む-

MinGW MSYS

どうもMSYSのバグが濃厚になってきたので、カテゴリにMSYSを入れてみた…
まずはハングするサンプルプログラムを作ろうと思ったが、中々ハングしないので、いったん諦めて、Makefileの軽量化に取り組んでみた。
最大ジョブ数を2(-j2)にして、同時に動作するmakeツリーを3パス作ったら、それだけでmakeがハングした。同じMakefileを-j1(パラレルmake無効)で実行すると、問題なく動作する。どんだけしょぼいんだコイツわorz。で、ログをチェックすると、やはりCHLDシグナルを捕捉できておらず、readで止まっている。
MSYS DLLのログ量を調節しながら何が起きているかを調べてみるが、makeがごちょごちょ色々な事をしているので、ログが複雑になり手が付けられない。と言うか、MSYS DLLって奇妙なコードが多くて走るコードを追っかけきれん(ﾟДﾟ;)
かろうじて読み取れたのは…

続きを読む

パラレルmakeがハングする理由を調べてみる…再起動-序盤-

MinGW

もうすぐ連休で纏まった時間が取れそうなので(学生さんは、もうすぐ夏休みですね〜)、このネタをもう少し引っ張ることにした。と言うか、纏まった時間ではない昨日も調べてたんですけどね…。
make v3.82を使っても、最新MinGW+MSYS環境上ではパラレルmakeがハングするので、前回よりも、もう少し深掘りしてみる。何度か(ではないな。かなりの回数)試してみると、希に動くときがある。ログを確認するとmakeツリーの探索よりも、運良くコマンド実行が先に実施されると、パラレルmakeが正常に動作する。このケースでは常に最大ジョブ数未満で処理が進んでいくため、パラレルmakeができる様だ。とは言っても、レアケースなので、このパスは無視することにする。と言うわけで、殆どの(ハングする)ケースが、どこのパスを走っているかを追ってみた。

続きを読む