トラブル発生時の解決法
これを読まれる方々へ
本ページの記述は「私なりの問題解決・回避方法」であり， 一般的でない and/or 根本的でない方法も含みます． 私の本業は Linux の利用法紹介や問題解決ではなく， 大気環境科学(気候学・気象学，大気質科学)に関する研究です． したがって，単なる研究道具に過ぎない Linux でトラブルが発生しても， 研究の進捗に影響が出ない限り 『解決』でなく『先送り』で済ませています． あらかじめご了承ください．
もし明白な間違いなどがあれば，ご指摘ください． 速やかに内容修正 or 公開停止の措置をとります．
プログラムの強制終了
プログラム実行すると，自分の意図に反した実行状態(いわゆる暴走)になる事がある． そんな時には，該当するプログラムを強制終了すれば良い． 自分で動かしたプログラム・コマンド類ならば，自分自身で(一般ユーザ権限で，の意) 該当プログラムを強制終了できる． 手順は以下の通り:
- 該当するプログラムのプロセス番号 (process ID) を確認 (使用コマンド: top, ps, pstree など)
- 強制終了 (使用コマンド: kill)
プロセス番号の確認
プログラム実行後，
- 想定以上に時間がかかる
- 画面表示されるはずの情報が出ない
- 計算機の応答が悪くなった(重くなった)
などの症状が出ているなら，実行したプログラムが暴走している可能性がある．
top, ps, pstree
実行したプログラムの挙動で，「何かおかしい」と感じたら， とりあえず top コマンドで稼働状況を確認することをすすめる．
無限ループなどのため暴走してる (CPU使用率がほぼ100% になっている)なら， top での表示は上位にあるはず． メモリの使用量は想定した範囲内か， 実行時間が予想以上に長すぎないか，などを確認．
長時間持続の場合では Case 1: 同一のプロセス ID が継続;
Case 2: 異なるプロセスが繰り返し実行，のどちらなのか ...
などなど，みるべきポイントは数多くある．
top コマンドの使い方，情報の読み方は，インターネット上に多くの説明があるのでここでは省略．
どうなっていたら「暴走している」のかは，状況により異なる． 特に，自分が作成したプログラムの場合には， 作成者である自分自身が「異常である」事を見つけねばならない．
プロセス番号 (process ID; PID と略記)を確認するには， ps コマンドを使う:
例: シェルプログラム名 hoge.sh の場合 $ ps -elf | grep hoge
process ID (PID) の「親子関係」(ツリー構造)を確認したいなら，pstree コマンドが有効:
$ pstree -p | less $ pstree -p -u 1 | less (2つとも同じ挙動になる．プロセス番号1以下，つまり全プロセスをツリー表示)
パイプで less につないで渡しているので，プログラム名などを文字列検索すれば， 比較的簡単にPIDとそのツリー構造がわかるだろう．
プロセスの強制終了
使うのはただ一つ．kill コマンド．
$ kill PID PID は Process ID の事．前述した top や ps コマンドなどで調査済みの番号を入力
もし上記でも終了できなければ，強制的にプロセスを切る:
$ kill -9 PID または $ kill -KILL PID
最初から kill -9 使っても別に問題ない． "-9" の意味など，詳細を知りたければ後述の参照情報を確認の事．
なお，暴走したシェルプログラムを強制終了する場合は，暴走していた コマンドの停止が最優先だが，暴走コマンドを呼び出していたシェルプログラム自体の プロセスを停止する必要があるかもしれない． シェルプログラムの中で for/while などの繰り返し処理をしている場合が該当．
暴走コマンドを kill しても，すぐに次の繰り返しを開始してしまうため． トラブルの根本であるシェルプログラム自体を停止すれば， 延々と kill を繰り返すことをしなくて済む．
参照情報
- [プログラムを強制終了する] - Linuxコマンド逆引き大全: ITPro -
- プロセスにシグナルを送信する - UNIXコマンド辞典: CodeZine -
- ハングアップしたプログラムを強制終了するには - atmark IT Linux Tips -
OS移行
See Linux 個人設定(hysk) # PC移行・OS更新時の作業工程
個別ソフト・デーモン
munin関連
2011-08-17: PC移設時，munin ページ閲覧でトラブル． default で .htaccess が存在することを忘れていたため． localhost からの閲覧も出来なくなった事で，少々時間を費した． .htaccess を削除し，/etc/httpd/conf.d/munin.conf を作成， httpd の allow/deny によるアクセス制限だけにした．
GNOME 関連
GNOME アプリが落ちる
2014-02-22: CentOS 6.5 において，GNOME のアプリが Segmentation fault で落ちるようになった． 自分が確認したのは，gnote, パフォーマンスメータ，時計など． yum update での更新後(VMware Fusion 5上)， およびCentOS 6.5 のネットワークインストール(新規; 自宅用Linux PC) したもので発生を確認．
原因特定できなかったが，更新・インストール時のパッケージがたまたま壊れていた という可能性が考えられた． そこで，GNOME 関連パッケージを一度アンインストールし，再インストールした (See also yum グループ関連オプション)．
$ sudo init 3 (X環境を終了，ウィンドウシステムなしの，ターミナル画面に移行) $ sudo yum groupremove "X Window System" "Desktop" (ウィンドウシステム関連をグループ単位で削除; 概算 3GB) $ sudo yum groupinstall "X Window System" "Desktop" (一旦削除したものをそのまま再インストール; 概算 300 MB) (削除した容量と再インストールする容量は一致しない． 依存関係に起因すると思われるが，原因追求にかける時間がもったいないので放置) $ sudo yum -y install gedit gnote gcalctool ibus ibus-anthy gnome-utils (上記のgroup再インストールで戻しきれないものを手動インストール) (gnote: 付箋アプリ, gnome-utils: GNOMEのユーティリティ群．スクリーンショットなど) $ sudo yum -y install evolution libreoffice* (必要ならば．個人的にはなくても特に困らない)
GNOME 関連アプリが落ちることはなくなった． しかし，GNOME のアプリケーションメニューから幾つかの項目が なくなり，すぐに復旧することができなかった． 個人使用で困らないので放置，使ううちにアプリの追加インストールすれば， そのうち復旧するだろう．
私の環境では，CentOS 6.x 系列でのトラブルが解消できなかった． そのため，私にしてはかなり早い段階で CentOS 7.0 へ移行 (2014-10-27)． See Linux 個人設定 (hysk) # PC移行・OS更新時の作業工程
復旧できなかったメニュー類(アプリケーション; Applications)
- 「アクセサリ」以下，「スクリーンショットの取得」; gnome-utils のインストールで復旧 (2014-02-24)
- 「サウンドとビデオ」以下全て
scim関連
2011-08-16: scim に関するトラブル． PC移行時に発生． ドットファイルを含め，旧PCの自分の $HOME 以下を 新PCの $HOME 以下に丸ごとコピーしたため， 新規PCでの環境との齟齬が生じていたらしい． 今後は，安易にドットファイルまるごとコピーしないようにする (参考: バックアップ(個人用ファイル)の 旧環境をまるごと移設すべきでないもの)．
エラーメッセージ: "An invalid char is given at scim_bridge_string_to_uint (): -"
目に見える現象としては， 「ウィンドウマネージャがフリーズしたように見える」， 「マウスカーソルは動くが，アクティブなマウスカーソルがきちんと表示されない」， などの症状． /var/log/messages に，下記のようなエラーメッセージが流れ続けているなら， scim 関連の問題．
Aug 17 10:08:02 hoge scim-bridge: No such IMContext Aug 17 10:08:02 hoge scim-bridge: An invalid char is given at scim_bridge_string_to_uint (): - Aug 17 10:08:02 hoge scim-bridge: Invalid message: Close the connection. Aug 17 10:08:02 hoge scim-bridge: Panel client has not yet been prepared Aug 17 10:08:02 hoge last message repeated 3 times (hoge 部分にはホスト名が入る)
対処法は，$HOME/ 以下の .scim ディレクトリを削除すること (Remove .scim directory under your home directory)． 次回ログイン時に再作成されるので問題ない．
ネットワーク関連
サスペンドからの復旧時(ネットワークデーモンが落ちてる)
CentOS 7.x 系列になってから，サスペンド機能がまともに動作することに気づく． ただし，およそ10回に1回程度の頻度で，サスペンド状態からの復旧時にネットワークが正常認識しなくなる．
See also 管理コマンドのメモ (hysk) # systemctl (CentOS 7系列), セキュリティ対策 (hysk) # サービス停止.
下記のように，systemctl にて restart (NetworkManager & network) する． 抜本的な解決ではないが，たいした手間でもないのでこれで良しとする．
$ sudo systemctl restart NetworkManager $ sudo systemctl restart network
SSHの応答が極端に遅い
(2016-03-10) ログイン出来るし，一旦接続されれば問題なく利用できるのだが， そもそもSSH接続時(IPで直接指定)にエライ(数十秒)待たされる... というような状況． 名前解決が失敗している事が疑われる．
修正点は下記:
- /etc/hosts に名前を入れる(サーバ・クライアントの両方)
- DNS の古い設定を削除(/etc/resolv.conf)，
- SSH daemon のDNS参照をoff (サーバ側の /etc/ssh/sshd_config で UseDNS no)，
- ~/.ssh/config にもサーバ名記載などを実施．
ただし，恐らくは /etc/hosts と resolv.conf からのDNS設定削除の2点だけで問題解決したであろう (全部一度に変更した後でテストしたため，問題特定してない．面倒なので原因未チェック)．
私の場合，職場が変わり以前とは異なるネットワーク環境に入ったにもかかわらず 以前から使っているLinux設定の一部を修正していなかったことで発生． メインマシンは移動直後に全ての設定を修正していたので問題なかった． しばらく時間が経過してから， メインマシンにLANかーどを二枚差しにして private LAN を構築， その private LAN 以下に サブマシンとして古いLinuxを接続した際に問題となった．
仕事を切り分けるために，それら2台は個別に独立した作業をする事が多く， 数日程度は障害に気付かなかった(KVMスイッチで画面等を切り替えて作業してたから尚更)．
yum 関連
See also yum の使用方法
yum update 失敗
原因は不明だが，ごく稀に yum update に失敗し， 以後のupdate が出来なくなることがある． そんな時， yum clean すると以後は正常になった．
$ sudo yum clean all 読み込んだプラグイン:fastestmirror, langpacks リポジトリーを清掃しています: adobe-linux-x86_64 base epel extras updates Cleaning up everything Cleaning up list of fastest mirrors $
yum で入れたソフトのインストール先が分からない
yum 単独では確認できない． yumdownloader にてRPMパッケージを取ってきてから，
$ rpm -qlp hoge.rpm (RPMパッケージの中身を確認)
yum のダウンロード速度が極端に遅い
fastestmirror が参照するホスト情報を削除，リセットする． See yum の使用方法 # プラグイン # fastestmirror
雑記
迅速な問題解決のために: 適切な質問の作法，質問する前にすべき事
以下では，卒業研究・修士研究などでLinuxを使う大学生・大学院生を対象としています． 博士課程の大学院生には，改めて言う必要がないことばかりです．
Linux を使っていて問題が発生した(自分では解決できない状態になった)際に， 自分では何もせず 「とにかく助けて!」と 管理者に問い合わせ(丸投げ)するのはやめましょう． 管理者でなく，ネット掲示板に丸投げするのも同じ． はっきり言って無責任です．
問題の解決方法を調べる手段は，(ネット以外でも)身近な所にもたくさんあります． 例えば，コマンド使用例やオプションに関する解説は，あなた自身が使っている Linux 中に存在してます (man & info コマンド)． もし調べ方さえも知らないのなら，研究室の同級生・先輩に聞くのが最良の方法． 自分と同じ悩みを，現在・過去に経験している(していた)人が， あなたのすぐそばにいるはず． これを活用しないと勿体ない．
身近な情報では解決できない場合には，インターネットは非常に有効な道具です． しかし，ネット掲示板・メーリングリストなどで質問する場合， 最低限のマナーとして 「自分の置かれた現状を過不足なく説明すること」 が必須です． 現状説明すら出来ない(または「説明する気が無い」)人は， そもそも Linux を使ってはならない人種です．
「『過不足なく説明』といっても，何をどこまで説明するのかわからない」 最初はそうでしょう． それでも，自分なりに考えて & 過去の質問なども参考にして， 説明を試みてみましょう．
ここで私が言いたいことは， 「最初は上手に説明出来なくても良い．他者に理解してもらうための努力をしなさい」， という事です． 初級者なら説明がヘタなのは当然． ですが，初級者の地位に安住して他人に頼りつづけるのは考え物です． 問題解決の手順を学習しない人は，自立した大人とは言えません．
どんな事でも，上手になるには訓練が必要． 最も効果的な訓練は，「失敗すること(恥をかくこと，とも言える)」でしょう． 恐れることなく失敗してください． ただし，同じ失敗は二度と繰り返さないように心がけましょう．
計画の立案: 小学生の頃に戻って，「なつやすみのよてい」を書いてみよう
卒業研究・修士研究の提出締切間際になって， 「とにかく誰か助けて!」 などと言って，身近な人たちやネット掲示板に援助を求める事態にならないように．
何よりも自分が損をします． 周囲からは，「計画性が無い」，「学習能力が無い」など 極めて低い評価を下されるでしょう キツイ表現ですが，「大学生(大学院生)にあるまじき，極めて幼稚な人物」 という，ありがたくない烙印を押されます．
卒業研究・修士研究などでは，〆切までの作業計画をたてるといいでしょう． 「計画通りに出来るわけがない!」 えぇ，そのとおりです． でも，計画通りにいかないという事実は，計画をたてないと実体験できません． これも重要な「失敗体験」の一つです．
多発するトラブルに悩まされている人: simple is best!
研究室の計算機トラブルが多発して困っている方， 「トラブルを減らすための配慮」をやっていますか? 大抵の人は忙しいので，とりあえずトラブルを解決したらしばらく放置するでしょう． でも，もしトラブルが多発して困っているなら... 特殊な設定をやめ，単純な設定に戻ってみてはいかがでしょう?
個人的意見ですが，もし Software RAID や論理ボリュームなどを使っているなら， それらを使用しない設定に変更することをすすめます． 無駄になるHDDスペースが増えるという弊害はありますが， トラブルの原因特定しやすくなると思います． トラブル後の復旧も(おそらく)早いと思います．
計算機管理が本業の人からすれば， 「なんで時代に逆行するような事を」 と感じるでしょうが， 道具として計算機を使えればいい，という立場からすれば 「多少効率は悪くてもトラブルなく稼働しつづけさえすればいい」 のです． たとえ最新の機能が使えなくても，きちんと動けばいいのですから．
更新履歴
| Date | Changes |
|---|---|
| 2016-03-10 | ネットワーク関連 # SSH の応答が遅いを追加． ネットワーク関連，yum 関連のサブ項目を左メニューに追加(忘れてた)． |
| 2016-02-21 | 節を再編成． munin, GNOME, scim などのトラブルが，最上位の節として独立させるほど多発していない． 今後，よほど増加するなら別立てすべきだが，現時点ではまとめてしまう． |
| 2014-02-22 | GNOME 関連を追記 |
| 2011-08-17 | scim 関連，munin 関連を追記 |
| 2009-xx-xx | 記録はないが，多分この頃に初稿作成． 千葉大 CEReS 在職時の FreeStyle Wiki を使っていた頃に作り始めたと記憶． |