StupidDog's blog

IT関連の手近な所で、疑問に思った事を調べた記録

「Ubuntu 12.10、起動時にChecking battery state...で停止する」の調査(2)

はじめに

前回の調査で、あたりを付けていた「power.sh」を調べる。

対象のファイル

/etc/power.sh

#!/bin/sh

test -f /usr/share/acpi-support/key-constants || exit 0

. /usr/share/acpi-support/policy-funcs

if [ -z "$*" ] && ( [ `CheckPolicy` = 0 ] || CheckUPowerPolicy ); then
    exit;
fi

pm-powersave $*

/usr/share/acpi-support/policy-funcs

#!/bin/sh

test -f /usr/share/acpi-support/key-constants || exit 0

. /usr/share/acpi-support/policy-funcs

if [ -z "$*" ] && ( [ `CheckPolicy` = 0 ] || CheckUPowerPolicy ); then
    exit;
fi

pm-powersave $*
usazukinchan@pc02:/etc/acpi$ cat /usr/share/acpi-support/policy-funcs 
CheckUPowerPolicy() {
	if pidof upowerd > /dev/null; then
		return 0;
	else
		return 1;
	fi
}
CheckPolicy() {
	local PMS
	PMS="gnome-power-manager kpowersave xfce4-power-manager"
	PMS="$PMS guidance-power-manager.py dalston-power-applet"
	if pidof -x $PMS > /dev/null ||
	   (pidof dcopserver > /dev/null && test -x /usr/bin/dcop && /usr/bin/dcop kded kded loadedModules | grep -q klaptopdaemon) ||
	   PowerDevilRunning ; then
		echo 0;
	else
		echo 1;
	fi
}

PowerDevilRunning() {
	test -x /usr/bin/dbus-send || return 1
	
	for p in $(pidof kded4); do
		test -r /proc/$p/environ || continue
		local DBUS_SESS=$(cat /proc/$p/environ | grep -z "DBUS_SESSION_BUS_ADDRESS=")
		test "$DBUS_SESS" != "" || continue
		(su - $(ps -o user= $p) -c "$DBUS_SESS dbus-send --print-reply --dest=org.kde.kded /kded org.kde.kded.loadedModules" | grep -q powerdevil) && return 0
	done
	
	return 1
}

「power.sh」は何をしてる?

「power.sh」は、何かをチェックして、最後に「pm-powersave」を実行している。

$ type `file -p pm-powersave`
/usr/sbin/pm-powersave: POSIX shell script, ASCII text executable
$ file 

「pm-powersave」は省電力モードへの移行と復帰を行うスクリプトらしい。
「/usr/lib/pm-utils/*.d/」以下のスクリプトを順次呼び出し、ログを「/var/log/pm-powersave.log」へ出力している。

今回の目的では無いので詳細は省き、「pm-powersave」が実行され終了しているか否かを確認した。
呼び出されたスクリプトをログで確認する限り、待ち状態で停止していない。

今回の調査結果

コンソール画面で表示されていた「Checking battery state...」は、まったく無関係である事が分かった。
この起動スクリプトより後で、障害が起こっていることが分かったので、今後は次に処理される起動スクリプトを突き止める。

おまけ

スクリプトを確認している際に、プロセスIDを調べる「pidof」コマンドが使われていたけど「-x」オプションで指定したスクリプトを実行しているシェルのプロセスIDを取得できるとの事。
スクリプトばかり追っているので、後々使えそう・・・コマンド覚えるだけで一苦労だな。