投稿日時 : 2009-06-08 01:44
Ubuntu9.04(それ以前のバージョンでも)でsmbfsを使用してWindows共有フォルダをマウントしていると、Ubuntuのシャットダウン(再起動)時に、
のようなメッセージ(#は起動毎に異なる数字が入る)が表示され、長い時間そのままフリーズしたようになる現象が起きます。しばらく待てばちゃんと終了されるんですが、気持ち悪いのでこの問題をなんとかします。
ちなみにシャットダウン時にこういったメッセージを見るには、「/boot/grub/menu.lst」のkernelオプションの「quiet」と「splash」を削除して再起動しておく必要があります。
MountWindowsSharesPermanently - Community Ubuntu Documentation
Electronic Genome - ランレベルとサービス起動プロセスのまとめ
ファイル詳細情報から
以下は関連ファイルの状態を確認しながら update-rc.d コマンドを実行したログです。
何が起こったかまとめると、
/etc/rc0.d/S31umountnfs.sh
/etc/rc6.d/S31umountnfs.sh
が削除されて
/etc/rc0.d/K15umountnfs.sh
/etc/rc6.d/K15umountnfs.sh
が生成されました。つまりランレベル 0 と 6 の時に /init.d/umountnfs.sh を優先度 31 で start を引数に実行させるためのシンボリックリンクが2つ削除されて、ランレベル 0 と 6 の時に /init.d/umountnfs.sh を優先度 15 で stop を引数に実行させるシンボリックリンクが2つ作成されたわけです。
実は大したことをしていないので手作業でもなんとかなりそうですね。
/etc/init.d/umountnfs.sh (91~108行目あたり)
まあ最近のWindowsのように「勝手なことすんじゃねー」と叫びたくなるほどお節介なのも問題ですが、ちょっとLinuxさわってみうようかなというライトユーザはこういうところで「やっぱりLinuxは難しい」と感じてしまうのではないかと思います。普及のためにも一考の余地ありかと思われます。
CIFS VFS: server not responding
CIFS VFS: no response for cmd ## mid ###
CIFS VFS: no response for cmd ## mid ###
のようなメッセージ(#は起動毎に異なる数字が入る)が表示され、長い時間そのままフリーズしたようになる現象が起きます。しばらく待てばちゃんと終了されるんですが、気持ち悪いのでこの問題をなんとかします。
ちなみにシャットダウン時にこういったメッセージを見るには、「/boot/grub/menu.lst」のkernelオプションの「quiet」と「splash」を削除して再起動しておく必要があります。
一時的な回避方法
エラーメッセージに「CIFS」があることからも、smbfsを利用したWindows共有フォルダのマウントに関係する問題だということが分かります。Ubuntuの終了プロセス中にWindows共有フォルダをアンマウントするわけですが、その際になぜかWindows側の応答待ちになって、タイムアウトするまでUbuntuがプチフリーズしている、といった挙動のように見受けられます。それならUbuntuの終了、再起動前にsudo umount -aとコマンドを打って、あらかじめアンマウントしておけばいいのでは?と思いやってみると一応これで回避できることを確認しました。
根本的な解決方法
一時的な回避策でうまくいくことからも、つまりはしかるべきタイミングでアンマウントされていればよさそうだということがわかります。そのあたりを調べているとubuntu.comの公式ドキュメントに情報を発見。MountWindowsSharesPermanently - Community Ubuntu Documentation
sudo update-rc.d -f umountnfs.sh remove sudo update-rc.d umountnfs.sh stop 15 0 6 .最後の「.」(ピリオド)を忘れないように。これでスムーズにシャットダウンできるようになります。
update-rc.d コマンドは何をしているのか
上記の update-rc.d コマンドが何をしているか簡単に言うと、Ubuntuの終了プロセス、再起動プロセス中に「umountnfs.sh」という名前のスクリプトファイルがいつ、何を引数に実行されるのかを設定しています。この「umountnfs.sh」がどこにあるか/etc以下を検索して、その詳細情報を表示してみます(update-rc.dコマンド実行前)。itmst@Ubuntu904:~$ sudo find /etc -name *umountnfs.sh -exec ls -l {} \; [sudo] password for itmst: lrwxrwxrwx 1 root root 22 2009-03-31 18:01 /etc/rc0.d/S31umountnfs.sh -> ../init.d/umountnfs.sh -rwxr-xr-x 1 root root 2140 2009-03-31 18:01 /etc/init.d/umountnfs.sh lrwxrwxrwx 1 root root 22 2009-03-31 18:01 /etc/rc6.d/S31umountnfs.sh -> ../init.d/umountnfs.sh「/etc/init.d/umountnfs.sh」がファイルの実体で、他の2つはその実体へのシンボリックリンクになっています。これらはLinuxのランレベル変更時に自動実行されるスクリプトの関連ファイルです。このあたりの話は以下の記事にまとめてあります。現在のUbuntuのディレクトリ構造とは多少異なりますが、動作原理はほぼ同じです。
Electronic Genome - ランレベルとサービス起動プロセスのまとめ
ファイル詳細情報から
- ランレベル 0 のときに /etc/rc0.d 中にある優先度 30 以下のスクリプトが実行された後に /etc/init.d/umountnfs.sh が「start」を引数に実行される
- ランレベル 6 のときに /etc/rc6.d 中にある優先度 30 以下のスクリプトが実行された後に /etc/init.d/umountnfs.sh が「start」を引数に実行される
以下は関連ファイルの状態を確認しながら update-rc.d コマンドを実行したログです。
itmst@Ubuntu904:~$ sudo find /etc/ -name *umountnfs.sh ←実行前に確認
/etc/rc0.d/S31umountnfs.sh ←シンボリックリンク
/etc/init.d/umountnfs.sh ←実体ファイル
/etc/rc6.d/S31umountnfs.sh ←シンボリックリンク
itmst@Ubuntu904:~$ sudo update-rc.d -f umountnfs.sh remove
Removing any system startup links for /etc/init.d/umountnfs.sh ...
/etc/rc0.d/S31umountnfs.sh ←シンボリックリンク削除
/etc/rc6.d/S31umountnfs.sh ←シンボリックリンク削除
itmst@Ubuntu904:~$ sudo find /etc/ -name *umountnfs.sh ←削除確認
/etc/init.d/umountnfs.sh ←実体ファイルしか表示されない
itmst@Ubuntu904:~$ sudo update-rc.d umountnfs.sh stop 15 0 6 .
↑ランレベル0と6用のディレクトリに優先度15のstop用シンボリックリンク作成
Adding system startup for /etc/init.d/umountnfs.sh ...
/etc/rc0.d/K15umountnfs.sh -> ../init.d/umountnfs.sh ←シンボリックリンク作成
/etc/rc6.d/K15umountnfs.sh -> ../init.d/umountnfs.sh ←シンボリックリンク作成
itmst@Ubuntu904:~$ sudo find /etc/ -name *umountnfs.sh
/etc/rc0.d/K15umountnfs.sh
/etc/init.d/umountnfs.sh
/etc/rc6.d/K15umountnfs.sh
/etc/rc0.d/S31umountnfs.sh ←シンボリックリンク
/etc/init.d/umountnfs.sh ←実体ファイル
/etc/rc6.d/S31umountnfs.sh ←シンボリックリンク
itmst@Ubuntu904:~$ sudo update-rc.d -f umountnfs.sh remove
Removing any system startup links for /etc/init.d/umountnfs.sh ...
/etc/rc0.d/S31umountnfs.sh ←シンボリックリンク削除
/etc/rc6.d/S31umountnfs.sh ←シンボリックリンク削除
itmst@Ubuntu904:~$ sudo find /etc/ -name *umountnfs.sh ←削除確認
/etc/init.d/umountnfs.sh ←実体ファイルしか表示されない
itmst@Ubuntu904:~$ sudo update-rc.d umountnfs.sh stop 15 0 6 .
↑ランレベル0と6用のディレクトリに優先度15のstop用シンボリックリンク作成
Adding system startup for /etc/init.d/umountnfs.sh ...
/etc/rc0.d/K15umountnfs.sh -> ../init.d/umountnfs.sh ←シンボリックリンク作成
/etc/rc6.d/K15umountnfs.sh -> ../init.d/umountnfs.sh ←シンボリックリンク作成
itmst@Ubuntu904:~$ sudo find /etc/ -name *umountnfs.sh
/etc/rc0.d/K15umountnfs.sh
/etc/init.d/umountnfs.sh
/etc/rc6.d/K15umountnfs.sh
何が起こったかまとめると、
/etc/rc0.d/S31umountnfs.sh
/etc/rc6.d/S31umountnfs.sh
が削除されて
/etc/rc0.d/K15umountnfs.sh
/etc/rc6.d/K15umountnfs.sh
が生成されました。つまりランレベル 0 と 6 の時に /init.d/umountnfs.sh を優先度 31 で start を引数に実行させるためのシンボリックリンクが2つ削除されて、ランレベル 0 と 6 の時に /init.d/umountnfs.sh を優先度 15 で stop を引数に実行させるシンボリックリンクが2つ作成されたわけです。
実は大したことをしていないので手作業でもなんとかなりそうですね。
S31umountnfs.shはいらない子だったの?
ところで、じゃあ削除された start 用のファイルはなんだったの?いらない子だったの?という疑問が浮かんだので /etc/init.d/umountnfs.sh のソースを見てみました。/etc/init.d/umountnfs.sh (91~108行目あたり)
case "$1" in start) # No-op ;; restart|reload|force-reload) echo "Error: argument '$1' not supported" >&2 exit 3 ;; stop|"") do_stop ;; *) echo "Usage: umountnfs.sh [start|stop]" >&2 exit 3 ;; esacstartを引数に実行しても何もしていないことが判明。やっぱりいらない子でしたw。引数が start と stop 以外の restart、reload、force-reloadやその他の場合はエラーを返しています。引数が stop (と引数なし)の場合は do_stop 関数を呼び出しています。結局、stop が引数のときしか処理が行われていないことが判明しました。
Linux普及に向けて
それにしてもsmbfsでWindows共有フォルダマウントするなんてUbuntu使いの多くの人がやることのような気がするので、デフォルトでシャットダウン時に umountnfs.sh を実行するようにしていてくれてもよさそうな気もするんですがどんなもんでしょう・・・まあ最近のWindowsのように「勝手なことすんじゃねー」と叫びたくなるほどお節介なのも問題ですが、ちょっとLinuxさわってみうようかなというライトユーザはこういうところで「やっぱりLinuxは難しい」と感じてしまうのではないかと思います。普及のためにも一考の余地ありかと思われます。
スポンサーサイト
Trackbak URL:http://itmst.blog71.fc2.com/tb.php/171-731df2d9