ここで出ている問題は、前回分に追記した内容で解消したっぽい。
なので、無駄な記事になってしまった。
--2017/04/20追記ココまで--
前回の調査で、どうやらOS起動時のファイルシステム(iSCSIボリュームで作成したLVM領域のファイルシステム)マウント、OS停止時のファイルシステムアンマウントの流れがおかしいのでは？というのが予想出来た。
そもそもこの領域、iSCSI領域であり、OpenvSwitch上の仮想スイッチを経由してiSCSIターゲットへ接続している。
(サーバとして使うのなら、iSCSIターゲットへの接続は独立したネットワークを用い、OpenvSwitchを経由しない構成にするべきだと思うのだが、自宅PCレベルでは複数NICや複数N/Wを使いまわすのは面倒だ…)
そのため、OS起動からファイルシステムマウントまでは、以下の流れにならないといけないと思う。(CIFSマウントのタイミングもついでに書いておいた。)
停止はこの逆になるはず。
根本的なところで、OpenvSwitchが起動した後に、iSCSIのLVM関連が動き出さないといけないのだが、どうやら起動処理ではこの順番が守られていないように見える。
また、停止時もこの逆になっていないように見える。
これを追いかけてみよう。
まずは再起動をして、サービス起動が上手く行っていないものを探す。
(gemini) $ sudo shutdown -r now
(gemini) $ systemctl -a status
今のgeminiは、以下のような状態になっている。
● gemini
State: starting
Jobs: 3 queued
Failed: 1 units
(略)
● dev-mapper-vg\x2d\x2dkvm\x2dlv\x2d\x2detc\x2d\x2dlibvirt.device
Loaded: loaded
Active: inactive (dead)
(略)
● dev-mapper-vg\x2d\x2dkvm\x2dlv\x2d\x2dvar\x2d\x2dlib\x2d\x2dlibvirt.device
Loaded: loaded
Active: inactive (dead)
(以降省略)
みたいな感じだ。
なんか、表示が上手く行っていないが、
dev-mapper-vg--kvm-lv--etc--libvirt.device
とかのようだ。
末尾が.deviceとなっているunitは、deviceタイプと呼ばれる代物。
実体は何処にあるかと言うと…無い…。
どういうことだろ…。deviceタイプはチェックしなくていいのかな？
一応、確認はしてみる。
(gemini) $ systemctl status dev-mapper-vg\\x2d\\x2dkvm\\x2dlv\\x2d\\x2detc\\x2d\\xwdlibvirt.device
Timed out waiting for device dev-mapper-vg…
う～ん。どうやら、デバイス(vg)へのアクセスがタイムアウトを起こした、ということらしいな。
ということは、vg構成情報が読み取れる状態になるところ(iSCSIログイン？)に問題があるのか？
systemdのユニットは、service/deviceの他に、mount/target等があるようだ。
ということで、一応mountも確認してみるか。
mount関連はココにも書いた通り、/run/systemd/generaterの下に自動生成される。
試しに、etc-libvirt.mountとmnt-iso\x2dos.mountを見てみると、以下のようなエントリが見える。
Before=remote-fs.target
これは、自分自身(etc-libvirt.mountとかmnt-iso\x2dos.mountとか)よりも後に、remote-fs.targetを起動する、という設定。
前提条件を書いているのではなく、後続条件を書いていることになる。
ちなみに、remote-fs.targetは、今の自分の環境には2つ存在してる。
/etc/systemd/system/multi-user.target.wants/remote-fs.target
/lib/systemd/system/remote-fs.target
が、実体は後者で、前者はシンボリックリンクだ。
前者はSysV init方式で言うところのrunlevelを制御するところの関係なので、今回はちょっと無視する。
後者を確認しよう(前者はシンボリックリンクなので、どちらを確認しても同じなのだが…)。
以下の3行が気になる。
After=remote-fs-pre.target
DefaultDependencies=no
Conflicts=shutdown.target
これを見ると、remote-fs.targetは、remote-fs-pre.targetの処理が終わってからでないと起動しないらしい。
また、shutdown.targetとConflictsになっているため、shutdown.targetと同時起動はしない。
DefaultDependenciesは…ちょっと良くわからない。標準的な依存関係を暗黙的に有効にするかどうか？で、noに設定されているので、幾つかの標準的な依存関係は無視される？
remote-fs-pre.targetも同じディレクトリにあるので、こちらもついでに確認する。
特に何かが書いてあるわけではない。
RefuseManualStart=yes
ってのがあるが…これがyesなので、ユーザの手作業による起動・停止は出来ないようだ。
これらをまとめてみると、以下のフローになるのかな？
さて、ココを調べてもしょうがない。
もっと上位で問題が起きていて、ファイルシステムマウントまで辿り着いていない、というのが現実だ。
とは言え、etc-libvirt.mountを見ても前提条件が書かれていない。
ステータスを見てみると…
(gemini) $ systemctl status etc-libvirt.mount
Dependency failed for /etc/libvirt.
となっていて、Dependency(依存)の失敗が原因となっている。
一体どういうことなんだろう…。
やはり、iSCSIログインに問題があるのだろうか？
と思って、NAS装置の管理画面からiSCSIターゲットを見てみたら、一応ログインされているようだ。
iSCSIログインに関するsystemd unitは何だろうな…
(gemini) $ systemctl | grep -i iscsi
iscsid.serviceのようだ。ステータスはrunningだから問題無い。
(gemini) $ systemctl status iscsid.service
cannot make a connection to....
あれ？なんかエラーっぽいメッセージが出てるな…大丈夫か？
一応、iscsid.serviceを再起動してみるか…。
(gemini) $ sudo systemctl restart iscsid.service
(gemini) $ systemctl status iscsid.service
おや？先程のエラーっぽいメッセージは出なくなった。
でも、vg情報は取得されてないぞ…。
む？もう1つ、open-iscsi.serviceってあるけど…これ…は？
(gemini) $ systemctl status open-iscsi.service
正常に動いているっぽいけど、一応再起動してみる…。
(gemini) $ sudo systemctl restart open-iscsi.service
ログイン済みのiSCSI targetからログアウト→再度ログイン、という流れになるはずなんだけど、syslogを見てみたらログアウトに1分30秒かかってタイムアウトした。
その後、再ログインしてデバイス認識はスムーズに行っている。
もしかして、これでvg認識されたかな？
(gemini) $ sudo pvdisplay /dev/sda1
ダメだ。ハングする。
他にも問題を抱えているのか…。
iSCSIイニシエータのエラーっぽいメッセージが消えたから、今度はLVM関連のサービスを確認してみるか。
(gemini) $ systemctl status | grep lvm2
lvm2-activation-net.serviceというのがあるな。
これの内容は…おや？これも自動生成関係っぽいな。
(gemini) $ man lvm2-activation-generator
lvm.confでlvmetadが無効化されている場合に、このlvm2-activation-generatorによってユニットが生成され、LVMボリュームがアクティベートされる、と。
gemini/cancerは、CLVMを使用する関係で、lvmetadを無効化している。
となると、今のaquarius/sagittariusとは条件が違うか…。まぁaquarius/sagittariusも将来的にはlvmetadを停止することになりそうだから、調べておくか。
どうやら、/run/systemd/generatorに、
lvm2-activation-early.service
lvm2-activation-net.service
lvm2-activation.service
という3つのユニットが作成されているっぽい。
これが関係あるかもしれない。
1つずつ確認してみよう。
まず3つのユニットのExecStartだけど、全て同じで
ExecStart=/sbin/lvm vgchange -aay --ignoreskippedcluster
になっている。
つまり、lvm.confのauto_activation_volume_listに記載されているlvolのうち、Clusterマークが付いているボリュームを無視して、残り全てをアクティベーションさせるということか。
これだと、既にPVが認識できていることが前提条件になりそうだな…。
3つのユニットの依存関係を見てみると…。
lvm2-activation-early.service
After=systemd-udev-settle.service
Before=cryptsetup.target
Before=local-fs-pre.target shutdown.target
Wants=systemd-udev-settle.service
lvm2-activation-net.service
After=lvm2-activation.service iscsi.service fcoe.service
Before=remote-fs-pre.target shutdown.target
lvm2-activation.service
After= lvm2-activation-early.service cryptsetup.target
Before=local-fs-pre.target shutdown.target
Wants=systemd-udev-settle.service
After/Before/Wantsが定義されている。
これらの依存関係を整理すると…
こんな感じだろうか…。
これ、1つずつ実行してみる。(最後のshutdown.targetは実行しちゃダメだよ)
(gemini) $ sudo systemctl restart systemd-udev-settle.service
(gemini) $ sudo systemctl restart lvm2-activation-early.service
あれ…？ココでハングした…？
--以下は想定していたコマンド。上でハングしたので実施せず。
(gemini) $ sudo systemctl restart cryptsetup.target
(gemini) $ sudo systemctl restart lvm2-activation.service
(gemini) $ sudo systemctl restart iscsi.service
(gemini) $ sudo systemctl restart lvm2-activation-net.service
--ココまで
う～ん。なんだろう…？
ちょっと調査を続けていたら、ココで設定したgemini/cancer共用のiSCSIターゲットへの自動ログインがOffになってた。(geminiだけ。)
たんなる作業ミスなのか、一連の作業の中で自動的に解除されたのかは不明。
とりあえず、「iSCSIを利用しようその1」等に従って、自動ログインを実施するように設定。
この状態で一度再起動をしてみるが、まだ解決できず。
とりあえず、調査は継続するけど、今回はここまで。
0 件のコメント:
コメントを投稿