Previous Topへ Next

OSXのtips6-10

今まで運用記録に書いてきたシステム運用のtipsを一カ所にまとめることにした。 要するに記事の量が当初の想定よりも多くなってしまい 私自身探すのが大変になってきたからだ。 ちょっとしたメモとしてのtipsも結構重要な情報になったりするので ここで項目を集めることにした。

anchor

Windowsのローカルフォルダにドライブレターを割り当てて「マウント」する方法

Windowsのドライブレターの割当の方法についての自分向け覚え書き。

Windowsのドライブに自由にドライブレターが振れるというのは前から知っていたのだが、Windowsの場合そのドライブレターを振る相手はリアルなドライブやディスクイメージでなくてもいいということを最近知った。

極端な話内蔵ディスクの中にあるディレクトリにドライブレターを振って「仮想ドライブ」にすることができる。

これが何に役に立つかというと、外部のドライブ・・・例えば外付けハードディスクとかの関係を切りたいがそこにリアルタイムで動いているサービスを止めたくないというようなケース。
実は最近仕事でそういうケースにあたって、こういう方法があるのだということを知った。
これはドライブレターがあるWindowsの独特の知恵だと思う。

例えばサーバの上で動いているサービスアプリ。
リアルタイムにログを吐いていて、そのバックアップをまた数分に一度というポーリング頻度で外付けハードディスクにバックアップしている・・・というような構成にしているとする。
Cドライブ上でサーバが動いており、バックアップ先は外付けのZドライブ。

この時にこの外付けハードディスクを交換する、あるいは修理対応でしばらく外さないといけないとなった時、バックアップ先のドライブを変更して再起動しないといけない。
このサーバーアプリが実はそう簡単にいつでも気軽に再起動できない種類のサービスを提供していたら、この作業は面倒なことになる。
例えば放送用とか、各種の自動サービスの中枢とか。

たかがバックアップ用の外付けハードディスクを外すだけでサービス全体を止めるのも・・・という向きには使えるTipsだと思う。
特にアプリの性格上各ドライブの直下にしかバックアップを置けないという場合は役に立つ。

他にはどんな時に役に立つのかな・・・多分サーバと共有関係が絡んでくる場合だと思うけど。

参考にしたのはこちらのサイト。

スーパーユーザーのためのWindowsコマンド再入門:substーパスをドライブ名に割り当てーITmedia エンタープライズ

WindowsXPでローカルフォルダにドライブをマウント(割り当て)する方法(仮想化)ーMiuxMiu

ディレクトリを仮想的なドライブとしドライブレターを割り当てるコマンドはコマンドプロンプトを呼び出して

subst Z: C:¥test
と打つ。

これでCドライブな直下の「test」という名前のフォルダがZドライブとしてマウントされる。
削除する方法は

subst Z: /d
と打つ。
くれぐれもそのままゴミ箱に捨ててしまわないように。

Macの場合はボリュームを見ているから、マウントされるのはデバイスとボリュームだけなのだが、Windowsの場合はこの方法で普通のディレクトリも仮想ドライブとしてマウントできる。
これは面白い。





仮想ドライブを作る方法は以下の手順
例えばCドライブ直下に「test」という名前のフォルダを作っておく
別にどこにどんな名前のフォルダを作ってもいいのだがここに置くのはパスが単純になるから




スタートボタンの「ファイル名を指定して実行」でフォームに「cmd」と入れてEnter
あるいはすべてのプログラムアクセサリー、システムツールから起動とどちらでもいいが
コマンドプロンプトを起動してsubset Z: C:¥testというコマンドを打つ
これはCドライブ直下のtestという名前のフォルダにZドライブを割り当てよという意味




するとマイコンピュータを開いた時にZドライブという新しいドライブが増えている
ドライブの大きさも空き容量もCドライブと全く同じだが
勿論ディスクの容量が倍になったわけではない




エクスプローラーで見るとこのZドライブはマイコンピュータの中に
他のドライブといっしょに並んでいてCドライブの中にあるわけではない
これを利用すればサーバアプリのログの保存先をこちらに変更して外付けハードディスクを
外せば再起動が必要ないのでサーバ管理者には柔軟な運用が可能になる筈だ



2011年5月26日









anchor

SMARTエラーを吐いたディスクを修復した〜まもなく実用試験にかける

先日TechTool Pro 6を紹介したのは、ネタがなくて専門誌に書いた記事のネタを使いまわしたわけではなくて、本当にディスクを修復するためにその手順を公開しようと思ってまず、ツールを紹介した。
(ほんとだよ、ネタ切れなんかじゃないんだからね)
( ´・ω・`)

こちらの記事で紹介した通り、MacBook Proの内蔵ハードディスクを交換した時にSMARTエラーを吐き始めたので、摘出した250GBをMac miniに移植することは断念した経緯がある。

MacBook Proのハードディスクを500GBに換装、Windows7を導入してみた

内蔵ディスクが死んだ〜SMARTのアラートが生まれて初めて役に立った〜その時の脱出法





先日TechTool Proを紹介したのはこのサーフェススキャンを利用したかったから
このスキャンでディスクプラッター上の不正ブロックを検出する
今回特に不正なブロックは見つからなかった




もし不正なブロックが見つかった場合もできることはあまりない
ディスクにゼロ消去をかけることで次回のフォーマットから
不良セクターヘの読み書きを回避する




この作業は250GBの場合およそ2時間かかった




次にフォーマットをかけたディスクを外付けハードディスクとしてマウントし
そこにCarbon Copy Clonerで内蔵ハードディスクのシステムをミラーリングしていく
Carbon Copy Clonerの最大のメリットは単純ミラーリングだけでなく
必要な領域を選択できるということだ




もうひとつのCarbon Copy Clonerの大きなメリットは
ミラーリングしたシステムから起動が可能なこと
これで完全なバックアップシステムも得たことになる
この作業は180GBほどの使用領域で4時間
クリーンインストールして環境を再現する時間よりはちょっと速い


こうして都合8時間の作業でSMART不良ハードディスクはリフレッシュされた筈だが、これが内蔵システムとして使えるのかどうかは、来週テストする。
以前にもディスクユーティリティでの修復はトライしているが、それでは改善しなかった。
ひょっとするとSMARTの場合は一度前科がついてしまうともうクリアできない可能性もある。
そこら辺SMARTについてあまり詳しいことを知らないのだが、やってみればわかるか。




2011年6月16日









anchor

AirMac Extreme導入〜概ねスムーズだったのだけどFTPサーバ公開に失敗?

表題の通り、無線LANのベースステーションを更新した。

これまで使っていたのは初代シロおにぎり型のAirMacBS(エクストリームとかはつかない)で、無線LANを導入した当初から使っているので、もうかれこれ7年になるか8年になるか。

2〜3年おきに無線LANポートが壊れるという人もいるそうだが、ウチの場合この初代が今もって元気。
だがさすがに時代の波には勝てないらしい。
最近で一番衝撃だったのはPPTP(VPNパススルー)に対応していないかもしれないということだった。 今時の無線LANポート、ルータで対応していないものはないそうなので当然対応品を使っているという前提で話が進んでいたが、ウチは対応できていなかったらしい。

さらに最近頻繁に落ちて接続が不安定になることがあったというのもある。
例のFTPサーバを上げてからは毎週のように落ちていたが、それ以前にも時々iTunesの無線スピーカーが落ちて使えなくなったりしていた。

設定は、実に安直なレビュア泣かせな方法でやった。

ベースステーションを物理的に入れ替えたら、「設定を引き継ぐ」で以前のネットワークの設定をそのまま引き継いだ。
AirMac ユーティリティが設定をバックアップしているらしく、ウイザードに従ってOKボタンをクリックするだけで繋がってしまった。

子機として使っているAirMacExpress2台も、Mac mini2台も、MacBook ProもiBookもすんなりつながる。
EPSONの無線LANプリンタも設定無しで繋がってしまった。
あっけない。

ところが、新型AirMacはちゃんと仕事を残してくれた。

先日建てたFTPサーバがどうやっても公開に成功しない。
WEBサーバの方はあっさり成功したのだが、FTPはどこをどういじってもうまくいかない。
仕事を残してくれたどころか、このひとつで折角のおニューほくほく気分が台無しかな。





設定はAirMac ユーティリティを使ってあっさり完了
バックアップされた前のベースステーションの設定をそのまま引き継ぐ




すべての設定を完了したところでwebサーバのiBookに固定IPを振る
これも前のAirMacではできなかったことでポートマッピングをやる関係でDHCPの
毎回再起動するごとにネットワークのそれぞれの端末に振るIPが変わる仕様は都合が悪い
AirMac ユーティリティのインターネット→DHCPタブに入って
「DHCPの予約」のところでサーバに希望のローカルIP を振ることができる




FTPパッシブモードで10個ポートを開く時の記述の仕方は確かこれでよかった気がするのだが
結論からいうとうまくいかなかったので後でいろいろな書き方を試した




web共有で80番、FTPで21番、FTP・PASV用に
42000〜42010番のポートを開く
WEBサイトはあっさり公開に成功しヘアピンモードでの
表示もできたがFTPはどうやっても繋がらない




ここでググりまくってあちこち解説サイトを読みあさった
なかには22番ポートを開くと良いなんてまじないみたいな解説まであってこれも試してみた
でも22番はsshのポートだよね、おおかたカンケーないんじゃないかな




結局どうやってもMacからもWindowsからもFinderCyberduck
Firefoxもこれまでに接続に成功したものはすべて試してみたけどこの通り
FTPはヘアピンモードが効かないのかもしれないと思い外からも接続して見たが同じことだった




ポートマッピングテーブルでカンマスペースで複数ポートを記述する方法を試したり
ポート一個ずつ書いてみたりしたがだめだった




ただしドメインネームの代わりftp://10.0.1.2/とやるとローカルではあっさり接続した
つまりローカルでFTP公開に成功しているがルータ兼用の
AirMacがルーティングに失敗しているということだ
原因はAirMacのポート公開の設定かFTPサーバのポート振り分けあたりに絞られた




結局今に至るまでFTP公開に成功していないが、それ以外はすべてうまくいった新型AirMac
サイズも段積みMac miniとぴったりなので、いよいよおせち料理かお重弁当のようになってきた
ミテクレに関しては大満足


ということでいまのところうまくいっていないのだが、FTPについてはこの2日間でかなり調べていろいろなことがわかってきた。

まず大抵の人が勘違いしていること(私も含めて)
20番ポートと21番ポートを使うFTPは21番がコントロールで20番がファイル転送ポートと解説されている。
そのために私もそうだったが、21番は登りポートで20番下りポートだと勘違いしている人が非常に多い。

実際はFTPはそんな単純なプロトコルではなくて、21番でファイルを投げるタイミングやACKをクラアントとサーバが双方に投げ合って転送が始まる。
アクティブモードの場合は転送に20番を使うが、ダウンロードもアップロードも20番を使うので、21番も20番も双方向通信となる。
決して上りと下りという仕分けではない。
だからアクティブモードの場合は、NATの背景にいるサーバの場合は20番と21番の両方をポートマッピングでサーバに誘導しないといけない。ファイアウォールも両方開いていないといけない。

PASVモードの場合は20番の代わりに任意の番号のポートを使う。
任意というのは1番から6万5千いくらのあたりまでの全域だが、1000番までの若い番号はいろいろ役割を振られているから大抵は50000番台〜60000番台あたりが振られることが多い。

PASVモードはアクティブモードと違って、サーバ側がファイル転送に使うポートを決定する。
ポートの番号はサーバが決めるが、ファイル転送のためのセッションのきっかけはすべてクライアント側がおこす。
サーバはパッシブにそのコントロールを待っているだけだ。
だからPASV(パッシブ)モードというのだそうだ。

そのコントロールに21番ポートを使うのでパッシブモードの場合は決まった番号は21番だけを開く。
ファイルを転送するポートは任意なのだが、この任意が問題だ。
1〜65536の任意のポートというんじゃ設定に困る。
実際には既存の用途が決められたポート番号とダブらないために、ほとんどのケースで50000番台から60000番台を使うらしいが、それでも45000以上のすべてのポートを開くというわけにもいかない。

そこで先日紹介したように今回FTPサーバのアクティベーションに使ったアプリのpure-FTPDでは42000〜42010番をファイル転送ポートに指定することが推奨されていた。
複数セッションに対応するのに備えて10個ほどのポートを用意しているが、その程度ならファイアウォールにも穴を開けられるし、ポートマッピングの設定もほどほどだ。

ところが思わしくない問題に気がついた。





WindowsでFFFTPを試していた時に認証に
42000-42010番以外のポートを使っていることに気がついた
コントロールの21番以外に認証もファイルリストもすべて指定のポートを使っていないとおかしい
ところが57650と出ているのはポート番号だろうか
これならポートマッピングされていないので失敗するのは当然だ


どうしてこういう現象が起きるのかは不明。

しかし前のAirMacでは成功していたし、その設定と全く変わっていない。
それで失敗するなら、AirMac Extremeの設定のどこかがおかしいことになる。
ところが現象として出ているのは、規定のポート以外のポートを使ってセッションを開こうとしている。
PASVの性格としてポート番号を決定するのはサーバ側だから、これはpure-FTPDがおかしいとしか言いようがない。
しかし42000−42010番ポートの設定はしっかり残っている。

あまり言いたくない言葉だがFTPアプリとAirMacの相性の問題なのか?
謎は深まるばかりだ。




2011年6月28日









anchor

仮想空間は断片化解消の夢を見るか?

ひとつの思考実験をする。

リアルな世界で、スペースがないところにものを詰め込む。
わずかな空きスペースを有効活用するために、詰めるべきものを分割して詰める。
その分割したものをちょっと足したりして、次回元に戻すためにさらに分割して違う空きスペースに詰め込む。

リアルな世界なら、そういう情景を思い浮かべることができる。
でもそれが、その分割したものの個数や形態を記述した文章だったらどうだろうか?

空きスペースも糞も文章なら関係ない。
書いて消せばいい。
どうせただの目録だ。
分割されてるとかされてないとか関係ない。


モノを蔵に詰め込む思考実験ならこんな感じかな。
どこに話を持っていこうとしているかわかるだろうか?

WindowsというOSは、異論もあるがデフラグ(断片化解消)はゼヒモノだと思っている。
やっぱり使っているうちに重くなってくる。
軽くするのにいろいろな方法があるが、結局劇的な効果があるのはデフラグだと思う。

リアルなボリュームにインストールされたWindowsならそうだが、もしこれが仮想化環境のディスクイメージにインストールされたWindowsなら断片化なんて関係あるんだろうか?

ディスクイメージとはファイルで、それはボリューム空間を復元するために記録された目録のようなものでそれ自体がリアルな蔵というわけではない。
イメージから再現された仮想的な空間が、普通のハードディスクの空間と同じになる。
ということは、そこに再現された空間には断片化なんて起こり様がない気がする。

ディスクイメージはいつも読み出しオンリーならば、そういう理解でスッキリしそうな気がする。
ところが世の中には書き込み、追記可のスパースバンドルというディスクイメージがある。
スパースバンドルの場合、追記、書き込みでスペースの割り付けが変わるのはリアルなハードディスクと同じだ。
だからここでは断片化が起きるのか・・・でもおかしいぞ?
記録しているのは目録で、ファイルそのものを蔵に入れているわけではない。
蔵に入れているイメージを保存しているだけだ、・・・
頭がこんがらがってきたぞ・・・

仮想空間では断片化は起きないのでデフラグは意味がない・・・これは本当だろうか?
以前こういう指摘を受けて、私もそう思うから、その通りだと答えたが、本当にその通りなのか?
わからないならさっそく実験だ。


自宅のファイルサーバ機Mac mini/intelにインストールしたVMWare FusionにインストールしたWindowsXPをデフラグしてみる。

これはMacBook ProのWindowsXPと違ってBootCampを使わないで、直接VMWare Fusionの仮想マシンにインストールした。
実体ファイルはWindowsXP.vmwarevmという名前のディスクイメージ(スパースバンドル)だ。

これをVMWare Fusionで起動したWndowsXPでデフラグする。
書いていて頭がこんがらがってくるが、結果は実にシンプルだった。





Mac miniの仮想空間にインストールされたWindowsXPはファイルが30%の断片化
軽い断片化状態だがすっきり!! デフラグを使って断片化解消してみる




その結果がこれ
断片化率は0%になり診断グラフも真っ青になった
そしてWindowsXPは起動も動作も軽くなった


ということで、仮想化空間であろうが実際断片化は起きるし、断片化解消は可能で、デフラグ(断片化解消)をかけると、OSの動きは軽くなった。

当たり前といえば当たり前っぽいが、驚きの結果でもある。
どういう仕組みで仮想空間のファイルの断片化が解消されるんだろうか。
それとも仮想化空間といっても、追記可能になった時点でリアルなボリュームと同じことなのか。
でも追記不可な仮想化空間とどう違うのか・・・
興味は尽きない。




2011年8月6日









anchor

Lion準備完了〜潮もかなひぬ 今は漕ぎいでな〜外付けHDDでインストールディスクを作成

世間の皆さんがインスコ大会で盛り上がっているのを横目で見ながら、雌伏しておりました。

実はとっくにダウンロードも完了していたのですが、いろいろあって置いていました。

何のことかって、←これのことです。

やはり仕事環境なんで、メインマシンのMacBook Proは。

それでここまでやってきたことは
1)起動ボリュームの外付けHDDへのクローンニング
2)外付けHDDからの起動でVPN、VNC、その他もろもろのネットワーク接続環境の確認
3)Lionインストールディスクメディアの作成
4)Lionインストールメディアからの起動、サルベーションの確認

というところをやっていて、今まで時間がかかっていました。

今回のLionの最大の驚きは、ついにDVDディスクでの販売をせずにダウンロードのみの販売となったこと。
Appleは本気で光学メディアの駆逐に乗り出そうとしているようで、かつてフロッピーにいち早く見切りをつけたように、今回はCD、DVD、そしてブルーレイも含めたすべての光学メディアに決別を宣言した気がする。

それはひとつの見識だと思うが、やはり手許にインストールメディアが残らないというのは不安なんだな。
古い人間とお思いでしょうが、システムがトラブった時にシステムディスクがあるのと無いのとではトラブルの対処法が全く変わってくるので。

それでまずシステムディスクを作ることにした。
といっても光学メディアではない。
光学メディアはもう死に行くレガシーメディアだという見識には私も賛成なので。





AppStoreからダウンロード完了したLionのインストーラ
いきなり「インストール始めるか?」と聞いてくるが
はやる心を抑えてまずインストールディスクメディアを作る
アプリケーションフォルダの中のMac OS X Lion インストールがインストーラの実体
これを右クリックして「パッケージの内容を表示」で中を見る




その中のContentsの中のSharedSupportの中の
InstallESD.dmgがインストーラのボリュームの実体
ただしこれをまるまるコピーするだけではインストーラの起動に失敗する




まずInstallESD.dmgをクリックしてマウントする
中身に「Mac OS X Lion インストール」があることに注目




ディスクユーティリティを起動してUSBメモリの準備をする




USBメモリをフォーマットする
通常USBメモリはMS-DOS(FAT32)でフォーマットされている
それをMac OS拡張(ジャーナリング)でフォーマットし直す
が結局失敗、容量が4.2GB必要なようで一般的な4GBUSBメモリでは失敗する
でもリカバリメディアはUSBメモリを使えという理由はあとで判明する




手許に8GBのUSBが無いのでUSB2.0接続の外付けHDDに
パーティションを切ってリカバリメディアにした
その時に気がついたのだがパーティションの最小単位は
25.4GBのようでそれ以上小さいパーティションは切れないらしい
たった4.2GBのリカバリシステムのために25GBのボリュームが専用になってしまった
昔は8GB単位で切れたような記憶があるが今はダメらしい
だからUSBメモリを用意しろということだったのか・・・もったいないが仕方がない




ボリュームをMac OS拡張(ジャーナリング)でフォーマット
ついでにでFirstAidもかけておく




次に復元タブに入ってソースを先ほどマウントしたInstallESD.dmgのボリューム、
復元先を今パーティション切りしたHDDのインストーラメディアボリュームに指定
これで復元をかける




確認タグにも「消去」でインストールメディアが完成




この外付けHDDのUSBシステムディスクから起動した様子
Lionのインストーラと同じだが各種ユーティリティが見える
Time Machineも見えているのでこれで壊れたシステム全体の復元も可能




そして現状のSnowLeopardのシステム、ユーザ環境を
私がもっとも信頼するCarbon Copy Clonerでバックアップする
Carbon Copy Clonerはファイルをコピーするだけでなくシステムのアクセス権なども
そのままコピーしてくれるのでコピー先のボリュームから同じように起動できる
現状もっともOSXを極めたバックアップアプリだと思う




USB外付けHDDから起動して仕事で必要なアプリ、接続環境がすべて動くことを確認
やはりインストール後使えないものもあるだろうからすぐに戻れる環境が必要なのだ
さて準備は整った!潮もかなひぬ、今は漕ぎいでな!


<追記>
ハードディスクは最小25GBまでしかパーティションが切れないと書いてしまいましたが、数値入力すれば8GBでも4GBでも切れるんだそうです。
気がつきませんでした。




2011年8月7日









anchor

Lion導入しました1〜いろいろ感じたこと

先日の予告通り、メインマシンのMacBook Proに置いていたLionのインストーラを起動させてクリーンインストールではなく、現在の環境の上にインストールするスタイルで入れてみました。

全体的な感想をいうと
1)上書きインストールなら環境のセットアップよりもTime Machineのセットアップにむしろ時間がかかる〜それくらい環境セットアップはあっという間
2)ウワサのスクロール方向逆転はやはり慣れるのに時間がかかる
3)全体的には表示は軽いOSという印象を受けたが、それは本当は軽いんじゃなくていろいろな技術を使って軽く見せていると思われる〜実際にはやはり重い大きいシステム
4)好評、不評相半ばのMissionControlは私はむしろ素直な操作性に戻ったということで歓迎している
5)Time Machineのスナップショットは強力だがやはり扱いに要注意
6)Swapの暗号化がデフォルトになってしまい解除できなくなっているが、扱うソフトによってはこれは致命的かも


こんなところですかね。

1)から順番に触れていくと・・・
インストールはやはり速いです。
犬の散歩の間に完了してしまったので正確な時間は測っていませんが、スノーレパード以前よりあきらかにインストール時間は短縮されています。

今回は調子を見るためにクリーンインストールではなく敢えて上書きインストールしたのですが、それだと環境の大部分を引き継げるので、ほぼインストールしたなりで使い始められます。
実際私がインストール後やったことって、ドックの背景が元に戻ってしまったので透明に戻したとか、ログイン項目で無効になっているものを外したとかそんなことくらい。
システムはほぼ問題なく動いていますから、仕事機で一日もお休みできないという人の場合、このアップデートは時間をとられなくていいと思います。

面白いなと思ったのは、LionのUpdateは今までのSnowLeopardでとっていたTime Machineのバックアップをそのまま引き継げます。
初回はシステムインストール分の10数GBのバックアップを要求されますが、あとは実にスムーズでまるでマイナーアップデートのように連続的に使えます。
ということはLionが気に入らなければいつでもSnowLeopardにすんなり戻せるということです。

ただ最初のバックアップは結構なスペースになりますので、Time Machine用HDDのスペースに余裕が無い場合は、バックアップの削除から始めないといけません。
これが何故か初回結構時間を食って、インストールよりも時間がかかってしまいました。
ディスク容量に余裕があれば問題ない話でしょうけど。





Lionインストールはいきなり2分と出るがさすがに2分では終わらない
でも画期的な速さで完了する




インストールが完了するとクロス風の背景のログイン画面にちょっと度肝を抜かれるが
ログインしてしまうといつものデスクトップが何食わぬ表情で現れる
そこにいきなりこのLionスタート画面が出るが「スクロールが逆になっているから慣れてね」
ということなのかもしれない・・・それくらいこれは混乱も予想されていたということか




後に別の必要があってログインしたrootユーザのデスクトップ
クリーンインストールのデフォはこんな感じということでしょう
SnowLeopardのやたら紫っぽいデスクトップよりは好みではあります




ディスクスペースがスッキリしたのはLionインストーラが自動削除されてスノレパも削除されたせい
まだ出たばっかりだから直後のUpdateもiTunesのアップデートくらい




あんまり普通なので思わずバージョン確認しちゃいました
間違いなくバージョン10.7、Lionです




事前に動かないことを知らされていたアプリはやっぱり動かない
MS Officeとは長いつきあいでしたが縁が切れそうです
ちなみにOpen Office.orgは普通に動きますので見るだけなら充分




Lionで一番問題なのはこの2・3フィンガースクロールの向きの問題でしょう
正直まだ慣れることはできないので変えたい人はシステム環境設定
「トラックパッド」あるいは「マウス」でスノレパ以前と同じに戻すことができます
しかしいくつかの理由があって私はデフォのままで使うことにしました




2・3フィンガースクロールの役割の割り付けもかなり変わってブラウザの戻る進むは
2フィンガーになったりこれも混乱しやすいところなのでシステム環境設定で戻すことができます
でもこれも敢てそのまま使うことにしました


Lionで一番混乱を生んでいる、そして一番賛否両論を呼んでいるのはこのスクロールの向きでしょう。
正直私もまだ慣れることができないので、意図しているのと逆方向にスクロールしてしまいます。

つとにあちこちで解説されていることですが、Appleがこの逆転を敢てやったのはやはりiPhone、iPadなどのiOSとの齟齬を解消するということが大きいのでしょう。


私たちはiPhone、iPodTouchのiOS以来、画面のオブジェクトをタップで掴んで指を上に撥ねれば対象は上へ流れていくという操作感に自然に慣れてきました。
掴んで動かしたい方向に指を動かす。
自然な操作感ですが、パソコンは今までこれが逆でした。
それはスクロールバーの制約があったからで、スクロールバーは長い領域の今どのあたりを見せているかを表示しなくてはいけないため、スクロールポイントは上を見ている時は上に、下を見ている時は下にないといけませんでした。
掴んで動かす時は上から下への移動は、スクロールポイントを掴んで上から下へ移動します。
その結果オブジェクトは下から上へ移動します。

Mozillaが最初に画面をグラブしてスクロールを採用した時も、このスクロールの原則に従って、マウスを下に動かすと画面は上に流れるという向きを採用しました。
これには非常に違和感を感じたことを思い出しました。

モノを掴んで下に下げたらモノも下に下がるのが自然で、上に上がっていくのは変だと思ったのですが、パソコンはスクロールバーの制約があったためにそれに従ったということでしょう。
最初は違和感を感じましたがやがてそれに慣れました。

しかし、iPod、iPhoneでタップして動かしたい方向に対象を動かすという操作感をAppleが提示すると、ユーザは素直にそれを受け入れました。
やはりパソコンのスクロールよりは人間の感覚に近い素直なインターフェイスだからで、またパソコンとは別物だからPCのスクロールと比較してどうこうという議論も特別起きなかったと思います。

しかし今Appleの工程表ではやがてiPhoneなどのモバイルOSとMacOSはiOSとして統合されることが発表されています。
この時にスクロールの向きがお互い逆だというのは大きな問題です。
そこでAppleはiPhoneの方に合わせるという選択をした。
こういうことなんじゃないかと思います。





Lionではスクロールバーが非表示になりました
デフォではスクロール時のみ表示になっていますがデバイス別で表示も可能です
iOSではつとに採用されている方式ですね




私の場合スクロールバーをクリックして離れた領域にいきなり移動とか結構使いますので
システム環境設定「一般」に入ってス「クロールバーの表示」常に表示にしています




スクロールアローは無くなりましたがスクロールバーの表示は従来通りです


Lionからスクロールバーが非表示になっています。
スクロール時のみスクロールポイントだけを表示するのはiPhoneなどのiOSと同じ方式ですが、Appleはあえてスクロールバーという概念を廃止しようとしているのかもしれません。

Mozillaの時に従来のスクロールに違和感を感じたけどすっかり慣れてしまったわけですから、むしろ同じようにこれから慣れるでしょうし、これから初めてパソコンを触る人達はむしろこの方が自然だと思われます。

この逆向きスクロールにどうしても慣れることができない人は、キャプチャー通りシステム環境設定で元に戻せますが、私は敢てこのまま使おうと思ったのはこれからのiOSの統合ぶりを見届けたいという気もちょっとあるからです。
皆さんは使いやすい方を選べばいいと思います。


3)全体的には表示は軽いOSという印象を受けたが、それは本当は軽いんじゃなくていろいろな技術を使って軽く見せていると思われる〜実際にはやはり重い大きいシステム

一般的な評判通りサクサク動くOSだと思いますね。
ただ折々やはりSnowLeopardよりも重いなと思わされる局面はあります。
特にメンテナンス系のMissionは重くなるものがあります。
おそらくは、いろいろ先読みしたりして見かけ軽く見せているWindows7と同じような技術が使われていると思われます。

4)好評、不評相半ばのMissionControlは私はむしろ素直な操作性に戻ったということで歓迎している
MissionControlには慣れることができないという意見もありますが、私はいい方向の改変だと思います。

もともとExposéはそんなに使っていなかったし、多重ウインドウの問題を解消する決定的な方法だとも思っていなかったので、SpacesDashboardと統合されたのはむしろ歓迎しています。

鳴り物入りで始まったコンファブリケーターを継承したDashboardも最近はすっかり下火なので、Spacesの中の一ページになってしまったのは妥当じゃないかと思います。

むしろ問題なのはSpacesの使い勝手で、これの設定が消えてしまったりというのがスノレパ以前のなんとかして欲しい部分でした。
Spaces重視のインターフェイスになったことはよいと思います。
この作業スペースの増減とか、使い方に関してはわかばマークのMacの備忘録のと頃の解説が例によって詳細で参考になります。





ExposéとSpacesDashboardを統合したMission Controlはよい流れの改変だと思う


5)Time Machineのスナップショットは強力だがやはり扱いに要注意
6)Swapの暗号化がデフォルトになってしまい解除できなくなっているが、扱うソフトによってはこれは致命的かも

この2項目については現在検証中の問題もあるので、後刻別項目で取り上げます。




2011年8月9日









anchor

Lion導入しました2〜暗号化Swap、スナップショットとかいろいろ際どい機能も盛り込まれている

Lion導入の感想の続き、というかちょっと困っていることもいくつかあります。

5)Time Machineのスナップショットは強力だがやはり扱いに要注意
この問題はこういうことです。

Leopardから導入されたTime Machineはバックアップシステムとしては画期的で、ほぼ意識することなく毎日のお仕事を保存してくれて
「やっちまった」
〜時でも、まるで時間を遡るように失われたファイルやシステムを復元してくれます。
これの強力さを実感したのはQuickTimeのアップデートに失敗して、システムが全面的不調になった時、外部システムから起動してシステム全域をアップデート直前の状態に戻せた時です。

イチからシステムの具合の悪いところを探して復元していたら何日かかるかという修復をわずか数十分で完了させるという強力さでした。

そしてLionからこのTime Machineは外部メディアだけでなく内部ディスクにも「余裕があれば」一時間ごとのスナップショットをとっていくスナップショット機能を備えました。

Time Machineはバックアップディスクを接続している時しか、バックアップを取らないという問題点もありましたから、出先でやっちまった時はやはりどうしようもなかったんですが、このスナップショットのおかげで、バックアップディスクが手許に無くても失われたファイルを復元できます。

すばらしいです。
すばらしいんですがちょっと困った問題もあります。
ディスクスペースがびっくりするくらい圧迫されることがあります。

これについては、今のところ応急的な対応法しか見つけきれていません。
詳細はキャプチャー参照ですが、結論のTime Machine設定でバックアップ領域から、大きなファイル操作をする領域(デスクトップやダウンロードフォルダなど)を除外するというんじゃスナップショットの魅力半減です。
スナップショットは必ず駆動するわけではなく、あくまでディスクスペースに余裕がある時だけということですから「気にしない」というのが正解なのかもしれませんが最大30GBものディスクスペースを食われるとさすがにちょっとなぁ〜。

いまのところ設定でオフにすることもできませんし、自由度の低いこのシステムはもうちょっとなんとかして欲しい気はします。





ちょっとイメージを一新したTime Machine
変わったのは見かけだけでなく内蔵ディスクスペースも
利用するスナップショット機能も追加されさらに強力になった・・・




と雑誌記事的には押しコメントで終わっていいのかもしれないけどちょっと困った問題も
例えば160GB空き容量があるように見えている内蔵ディスク・・・




Time Machineでは外付けHDDのバックアップは紫のラインで、
内蔵ディスクのバックアップは白のラインで表示される
外部ディスクにどこまでバックアップされたかは「最新のバックアップ」で示される
白い領域がスナップショットでここが増えれば
当然内部ディスクを圧迫することが予想される




ちょっと実験でUbuntuのシステムディスクをガンガンダウンロードしてすぐに削除・・・
すると見かけの空き容量は160GBのままですが
ディスクユーティリティで見る「実効ディスク空き容量」はどんどん減っていく




ついに20GB近く差が出てしまった「名目空き容量」「実効空き容量」
外付けHDDにつないでバックアップを取ると「実効空き容量」が増えるのではなく
「名目空き容量」が減るという不思議な動きをするし、どうなってんだ?




Ubuntuをガンガンダウンロードしていたらついに
名目と実効の差が30GBを越えたのでなんとかすることにした
ところがここでスナップショットの領域のバックアップは
「削除」メニューが無いことに気がついた




ディスクにバックアップしたら削除メニューが見える場合もあるけど
結局削除しても復元できる・・・ということはどこかに残っているらしい
ゾンビのようなバックアップでこの方法ではディスクスペースも復元できないことが判明
今までのTime Machineならこれでディスクスペースを取り戻せたので実にアンコントローラブル




さてこのスナップショットですが言ってみれば
Time Machineのミニチュア板のようなもので
24時間以内は1時間おきのバックアップを取りますが・・・




それを過ぎると一ヶ月までは間引きしながら保存します
つまりいくらディスクスペースを圧迫されても
気にしなければ「いつか消える!」ということです
でも気になります




そこでディスクスペースを圧迫しているディレクトリを除外領域に指定します
私の場合それがデスクトップフォルダだしあなたの場合はダウンロードフォルダかもしれません




こうして最大差30GB以上の名目と実効ディスク容量の差を6GBまで抑えることに成功しました
しかしデスクトップ領域を除外したんじゃ折角のスナップショット
意味が半減しますのでこの方法はお勧めしません
ディスク容量はたっぷり余裕をもって「細かいことは気にしない」
「金持ち喧嘩せず」がLionとのつきあい方の正解と思われます


次なる問題はこちらで、こっちはもうちょっと深刻です。
6)Swapの暗号化がデフォルトになってしまい解除できなくなっているが、扱うソフトによってはこれは致命的かも

各種アプリの動作テストをしていた時に、Final Cut ProをフルHDで動かしていた時にこういう問題が起きました。





システムの動きが軽いなら例によって各種アプリをガンガン起動して負荷テストだ・・・
ということで横綱登場、やっぱり負荷の王様はFinal Cut Proでしょう・・・




非圧縮のフルHDのプロジェクトのトリックプレイなどの負荷を見ていた時
通常再生で「コマ落ち」を検出しました
一般ユーザにはあまり関係ない話ですがこれプロの人達にとって結構深刻と思われます
再生でコマ落ちが起きるということは書き出しや取り込みでも
コマ落ちが起きる可能性があるということです
フルHDが標準になってしまった今ではこれでは仕事にならないです




いろいろいじってみた結果Swapをページアウトする時にコマ落ちが
起きやすいことがわかったのでSwapの量を調べていて気がつきました
LionからSwapは暗号化がデフォになったようで「暗号化スワップファイル」とあります
(後にこれはMacBook Pro、MacBook Airの仕様と判明)




SnowLeopard以前にはシステム環境設定「セキュリティ」「仮想メモリを暗号化」
という設定項目があったのですがLionからはなくなってしまいました
「いじるな」ということらしいです




いじるなと言われると余計いじりたくなってしまうんですね・・・
いろいろググってこの設定項目はX-Codeで開けることが判明しました
Terminalを起動して以下のコマンドを入力
open -a Xcode /Library/Preferences/com.apple.virtualMemory.plist
余談ながらLionのスモークスケルトンはWindows7と
同じように背景がぼやけるようになりました




ところがネットの記述と違いアクセス権をいじっても設定を保存できない
そこでrootでログインして同じコマンドで呼び出し




このUseEncryptedSwapのBooleanのチェックを外す




外した状態で保存・・・でいいはず




ところが再起動後Terminalを起動してsysctl vm.swapusage
というコマンドを打ってみると(encrypted)と出ます
つまりSwapの暗号化は解除されていないということで上記設定は無効化されているということか




いろいろいじってみたけど結局解決できず
Final Cut Proのアラートを見ているとRT Extremeの制限でこの問題は回避できそうだけど
今までそんなとこいじったことないし業務機ならそういう設定はデフォのままが義務でしょう
本職の皆さんはLionはちょっと様子見した方がいいかもしれないです
ただしアマチュアの皆さんのホームビデオなら全く問題ないと思われます
これはあくまで非圧縮フルHDでの話ですから


ということでどうやらこの問題はここで手詰まりらしいです。
一般ユーザにはほぼ関係ない話だし、この仕様はMacBook ProとMacBook Airだけらしいので、Mac ProなどでFinal Cut Proをいじっている人達はとりあえず安心して欲しいのですが、プロの環境ではMacBook ProなどでFinal Cut Proを動かすことがあるので、ちょっと問題です。
プロユーザはLionアップデートはちょっと様子を見た方がいいかもしれません。

他のAdobe Photoshopなどでは特に影響は無かったようです。
暗号化した仮想メモリでこういう大物ソフトに対応できることにむしろすごさを感じるべきなんでしょうけど、プロの使い方はレイヤーにしてもモーションにしてもガンガン使いまくるから、ちょっとリスキーだなと思われます。

他に気になったことは以下の通り





アプリを終了しないでログアウト・再起動すると次回その時起動していたアプリが
自動的に起動しているリジューム機能は個人的には大きなお世話だと思いました
例えばバックグラウンドで動かしているXBatteryのようなアプリが
気がついたら数十個のウインドウを開いていました
この機能はシステム環境設定「一般」で殺すことができます
速攻killしました




フォルダアクションがやけに敏感になったのか
エイリアスの上をドラッグして通過するだけで反応します
暗号化ボリュームのエイリアスを置いているといちいち
Finderがフリーズしたようになってパスワードを要求します
いくら反応時間を遅くしても改善しないのでデスクトップに
エイリアスを置くのを止めましたがこれも使い勝手的には問題です




これもつとにあちこちで触れられていることですがユーザライブラリが
見えなくなったのは使い勝手からいってだめでしょう




しばらく我慢していましたがやはりストレスになるのでchflags nohidden ~/Library
のコマンドをTerminalに打って表示することにしました
元に戻すコマンドはchflags hidden ~/Libraryです




これで従来通りライブラリフォルダが見えるようになりました
Apple的にはユーザライブラリも中をいじるなということなのかもしれないけど
ユーザフォルダはユーザのものだと思われます




さらに細かい問題はFinderのプレビューが何故か画像のサイズを表示しないことがあること
これも出たり出なかったりでプレビューで代用できるのですが
Webサイトクリエータには仕事の能率で問題が出るかも
全体的に「アタリがとれていない」印象のLionですが面白い機能もあるので今後に期待です



2011年8月9日









anchor

スナップショットを殺してみる〜やっぱり重いぞLion!?

先日OS10.7Lionを導入したことを書きましたが、この新OSなかなかのきおい獅子みたいで、すんなり飼いならせません。

現象としては新OSにしてから冷却ファンがずっと最高回転の6900回転に貼り付いていて、実際温度モニターを見ているとCPUが頻繁に80度を超えています。
Lionを使う時には、節電中の事務室ではなくサーバルームの中で使うのがよさそうです。

実際MacBook Proのそこは低温火傷しそうなくらい熱くなっています。

それとSwapが久しぶりに大増量しています。

MacBook Proに乗り換えてさらに物理メモリを8GBに換装してから、Swapは3つ以上に増えたことが無かったんですが、またガンガン増量してきて6つ2GBにまでいってまだ増えそうな勢いでした。 これじゃメモリ不足のiBook時代に逆戻りですので、この常に負荷がかかっている感じはなんとかしたいと思っています。

とりあえずツイッターに@gururiさんから情報を頂きましたので、ローカルTime Machine機能のスナップショットを殺すことにしました。





MacBook Proのメモリを8GBに換装して以来3つ以上に
なったことが無かったSwapがLion換装でいきなり6つ2GBに増えた
温度も電熱器のように熱くなってファンは常に最高回転で
温度に問題があったiBookに逆戻りしたような感じ




@gururiさんの情報に従ってスナップショットを殺すコマンドを実行
コマンドはtmutil disablelocalです




と、このコマンドはroot権限を要求されます
そこでsuコマンドでrootになって再度コマンドを実行




そうすると暴れ駒のようだったOSが少し落ち着いてTime Machineの見た目も変化しました




ローカルバックアップのスナップショット領域を示していた白いバックアップが消えて
従来のTime Machineと同じになりました




また外付けハードディスクを接続していなくてもTime Machine
入れるようになっていたがスナップショットを殺すと
ローカルHDだけの時にはTime Machineに入れなくなりました


キャプチャの通り、スナップショットを殺すコマンドは

tmutil disablelocal

元に戻すのは

tmutil enablelocal

となります。

これを殺すと、確かにOSは落ち着いてファンも上限に貼り付きっぱなしということも無くなっています。
さらに先日も書いたようにスナップショット領域でディスクを何十GBも圧迫するという動きもしなくなりました。

メリットはそういうことですが、これを殺すとTime Machine機能はバックアップディスクを接続しているときだけしか使えず、出先で何か問題が起きた時にローカルディスクで復元ができるスナップショットのメリットも無くなってしまいます。

ここは損得よく考えてやるべきでしょう。
こういう目玉機能を殺すならSnowLeopardでもよかったんじゃないかという気もしますが、とりあえず私はこの機能が改善されるまで一旦殺しておくことにしました。

ところでこのコマンド、またアプレット化できませんかね?
@kaoru_ari様?
rootのパスワードを求めてくるところがミソだと思いますけど、クリアする構文があった気がします。




2011年8月13日









anchor

LionでWindowsXPをVMWare Fusion上で動かすには〜ちょっと手こずりましたよ

Lionでは、WindowsXPは動かないという驚くべき噂を聞いて、ちょっと戦々恐々としていました。
いまだにメインの仕事環境はWindowsXPで当分7に移行しそうにないし、今私がかかわっている機器も、メディアサーバもファイルサーバも基本WindowsXPまたはWindows2003Serverというところで、この世代の検証環境を持っておくことは当分必要です。

Lion移行で一番引っかかっていたのはここで、これがクリアできないならSnowLeopardに戻ることも辞さないと思っていました。

さっそくVMWare Fusionのテストをすることにしました。
最初にBootCampボリュームの修復をするとのことで待たされます。
ここでいろいろ書き換えがされているようですが、ウワサ通りWindowsXPが動かないならEFIの書き換えがされているのかもしれません。

それで書き換えが終わってWindowsXPの起動が始まると起動失敗の表示とともに
「現在のVMファイルは互換性が無いので削除して新規登録し直せ」
というような意味の警告タグが出ます。
これにうっかり従ってBoot Camp.vmwarevmファイルを削除したりするともう二度とWindowsXPを起動できなくなる。

旧ファイルをインポートするのが正解。
VMWare FUsionでWindowsXPを使っている人達は要注意!





VMWare Fusionを起動してBootCamp環境のWindowsXPを
起動しようとすると「仮想マシンファイルを削除して新規登録せよ」という表示が出る
登録したBootCampから起動すると延々とボリュームを修復する




そして修復が完了して起動すると読み込むそぶりをするが結局起動に失敗する
これは何度やり直しても同じことで結局最初の指示に従って
仮想マシンファイルを削除してはいけなかった




ゴミ箱から仮想マシンファイルを救出してそれを「インポート」する
そこから起動すると2回ほど失敗したがやっと起動に成功
一度成功すると次回からは従来通り起動できるようになる




起動直後のWindowsXPは初期の頃のように異常に重い状態で
起動にも時間がかかるし動作の度に待たされる




インポートしたからだろうけど仮想マシンの設定がすべてデフォルトに戻っている
仮想メモリもデフォの512MBに戻っているので1〜1.5GBあたりに戻す




ネットワーク接続もNATに戻っている




今回も検証したがやっぱりブリッジ接続にした方がWindowsの動作が速くなる



2011年8月14日









anchor

Lionのシステムを軽くする〜hiutilの暴走を止めるには

導入以来ずっとフルアップしていて、動作も重いしファンも最高回転が続いていて熱暴走を起こしそうなくらい筐体が熱くなっているLion導入のMacBook Pro。

仕様というよりもどうもいろいろな要因が重なっているようです。
ひとつ気がついた要因と、その対処法を紹介します。

ログイン直後にCPUがほぼ100%にフルアップしている、それも常駐アプリが起動したあとも続いているという人はまずこれを疑ってください。
アクティビティモニターを起動してCPU使用率でソートすると
hiutil
というプロセスが80〜90%のCPUを使用しています。
しばらく時間が経つとhiutilは止まるけど、今度は
helpd
というプロセスがやはり相変わらず80〜90%CPUを使用してずっと動き続けています。
何をしているのかわかりませんが暴走しているものと思われます。

これについてはこちらが参考になりました。
hiutilの暴走およびクラッシュの対処...- Apple サポートコミュニティ

要するに常駐させているプロセスのどれかがHelpのdaemonとぶつかって暴走させているようです。
一番本質的な解決法はすべてのプロセスをひとつずつ止めて、再ログインして暴走が起きるかをチェックしていくということになりますが、気が遠くなりそうな作業になります。
多分セーフモードで起動すれば起きない暴走だと思われます。

対症療法的にはこの
hiutil
helpd

のふたつのプロセスを強制終了する
という方法で対処できますが毎回も面倒なので、
~/Library/Caches/com.apple.helpd/Generated
に作成されている.helpファイルのうち0KBのものを探して原因プロセスを突き止める

以下のふたつのファイル、フォルダを削除する
~/Library/Preferences/SDMHelpData
~/Library/Caches/com.apple.helpd


などの方法があります。
残念ながら私の場合はどちらも一時的な効果で、次回ログインの時にまた暴走が再現されるのでひとつずつ停止してログインテストをやるしか仕方がないようです。

ヘルプなんて役に立ったこと無いからすべてのアプリ、プロセスのヘルプファイルを圧縮してしまえばいいのかな。





ログイン後CPUがフルアップしてファンも最高回転、
筐体もちんちんに熱くなるという症状が続いていたが
アクティビティモニタで見てみるとhiutilという見慣れないプロセスがフルアップしている




これはヘルプ機能のユーティリティプロセスで普通フルアップするような性格のものではない
何かがうまくいっていないのでその原因を探るべく
~/Library/Caches/com.apple.helpd/Generatedに入っているファイルを大きさでソート
OKBのファイルがあればそれが犯人らしいのだが私のところには残念ながら無かった




そうこうしているうちにhiutilは引っ込んで今度はhelpdというプロセスが暴走し始める




とりあえず対症療法的にはhiutilhelpdのふたつのプロセスを強制終了することで暴走は止まる




ひょっとしたらうまくいくかもしれない方法もご紹介
~/Library/Caches/com.apple.helpdをフォルダごと削除





~/Library/Preferences/SDMHelpDataもフォルダごと削除
単にデータベースが壊れているだけならこれで改善するかもしれない




それでも改善しない場合は起動しているすべてのプロセスの
元になっているアプリのヘルプファイルを圧縮
アプリ本体を右クリックで「パッケージの内容を表示」
/Contents/Resources/Japanese.lprojの中のHelpと書いてあるファイルをZip圧縮してしまう


これでうまくいくのか今のところ検証中ですが、暴走している本体の正体が分かれば何とかなりそうな気がしてきました。

もう少し検証してみます。




2011年8月14日









anchor

Safariのセッション復元機能が無くなって困っていたが「リジューム機能」を使えということか・・・<追記あり>

先日Lionの新機能の「リジューム機能」が邪魔だからオフっちゃうという方法を書いたが、どうもあの設定でもリジュームが完全にオフになるわけではないらしいです。
どうも仮想メモリの暗号化解除といいこのリジューム機能といい設定が効いているようないないよう
な・・・よくわからない振る舞いをしています。

リジューム機能をオフにしてもXBatteryはやはり勝手に起動してしまい、起動項目に入れていると二重起動してウインドウの数がどんどん増えてしまいます。
それだけならXBatteryをオフってからログアウトするルールにするでもよかったんですが、リジューム機能をオフるとSafariの前回のセッションを復元する機能が見当たらないことに気がつきました。

私はブラウザのタブをいつも40〜50くらい開きっ放しにしているので、そのタブを次回起動時に復元してくれないのはとても困ったことです。
Safari5はタブの復元機能がついたと思って喜んでいたのですが、この機能はLionでは隠れる仕様のようです。
全く大きなお世話だなぁ>Apple

結局Safariはリジューム機能を使えということらしいです。
なのでリジューム機能を復活させて、XBatteryPath Finderはログアウトする前に必ず終了するというルールで運用することにした。

デフォの使い方が結局一番便利ということらしいです。





リジューム機能は邪魔な機能と思ったが50も開いたSafariのタブを
ログアウトの度に手動で復元しないといけないのは閉口する
消えてしまったSafariの復元機能はリジューム機能を使えということらしい




前にオフると書いたリジューム機能の設定を結局元に戻すことにした
オフったところでXBatteryの二重起動を防げないので元に戻すことにした




ところで余談をひとつ
同名フォルダを上書きすると全部を上書きするかタイムスタンプが
新しいものだけを置き換えるか聞いてくるようになった
Windowsのように5つもボタンが出ると混乱の元だが
これくらいの選択肢はあってもいい気はしていた
細かいことだけどこれもひとつの進歩だと思う



<追記>

BBSにtOmoriさんから書き込みを頂きました。
リジューム機能についてちょっと思い違いしていたのですが、システム環境設定の一般の設定は次回アプリを起動した時に前回のウインドウを復元するかの設定で、起動時に前回の終了時に開いていたアプリを勝手に起動する機能は、終了時のタグに出てくる
「再ログイン時にウインドウを再度開く」
のチェックを外すことで回避できました。

正常終了の時にはこのチェックを外せばXBatteryなどのウインドウがどんどん開く問題を回避できるのだけどいずれにしても、終了時にひと手間増えるのは変わらないようです。

これを設定で外すことができれば問題はなくなるんですが、この機能は不意に強制終了する羽目になったとき、フリーズの時とかに再起動後前回の作業中の状態を復元しようという「親切機能」ですから設定で外したりできると役に立たないわけ出し悩ましいところです。

とりあえず当座は
「再ログイン時にウインドウを再度開く」
を毎回外すことで、様子を見ることにしました。
情報頂いたtOmoriさんありがとうございました。





終了時、毎回「再ログイン時にウインドウを再度開く」
というチェックが終了確認タグに出るようになった
これを外せば次回ログイン時に意図しないアプリが開くことを防げるが
設定で無効にできないので毎回というのはちょっと面倒
無効にできると万一のときの保険の意味が無くなるのだが・・・



2011年8月14日









anchor

Lionのシステムを軽くする2〜上書きインストールは常駐daemonに要注意!!

いろいろカルチャー的、ビジネス的にいまメルクマール的位置にいるOSXLionなんだけど、導入後の感想を一言でいうと

とても調子が悪い

という状態でした。

この数日コントロールできないクラッシュが続いて、特に3日続けて朝クラッシュして早起きしているにもかかわらず会社に入る時間は遅刻ギリギリという日々が続いています。

何をやっているかというと外付けハードディスクを3つほどつないでバックアップをやっているということなんですが、これが朝起きると必ず
「使用中のためアンマウントできません」
となってディスクユーティリティを使ってもマウント解除できない、ログアウトしようとするとまっ白なスクリーンになって虹色ボールが延々回り続ける・・・何もコントロールできないので、仕方なしに強制終了する・・・キーボード操作、トラックパッド操作を一切受け付けない・・・再度強制終了・・・レスキューボリュームから起動して起動ボリュームの修復・・・再起動するがいつもの倍以上の時間待たされてやっと起動、ログイン というプロセスを判で押したように繰り返しています。

外付けハードディスクを修復しても特に異常は見られません。 問題のディスクはTime Machineのターゲットディスクではなく、手動でドロップしてバックアップを取っているディスク。





問題のクラッシュした時間帯をみるとWindowServer等いろいろなクラッシュが連鎖的に
起きていてこれが虹色ボールが回って何も操作できなくなった状態を示すと思われる
その少し前の時間帯を見るとGrowlHelperが延々とログを吐き続けていて
あまり論理的ではないけどとりあえずGrowlを外すかと一瞬思案した


<数時間後>
いや違う、
やっぱりちゃんとログは見ておかないといけない。
Growlは原因じゃなくて結果で、その前にLittle Snitchがdaemonと交替々々で延々とログを吐き出していて、それが飽和すると再起動する羽目になってその過程でGrowlがログを吐くという順序でした。

Little Snitchはこういうログを毎秒2〜3個吐き続けています。


Aug 27 01:57:41 hiiragi-no-MacBook-Pro com.apple.launchd[1] 
(at.obdev.littlesnitchd): Throttling respawn: Will start in 10 seconds

その合間にdaemonのエラーコードを吐くというプロセスを繰り返しています。

Aug 27 06:32:55 hiiragi-no-MacBook-Pro SecurityAgent[255]: 
NSExceptionHandler has recorded the following exception:
	NSPortTimeoutException -- connection timeout: did not receive reply
	Stack trace:  0x1033c8c69  0x7fff93c8fd5e  0x7fff9511c7ba
	  
0x7fff9511c744  0x7fff97627694  0x7fff95109984  0x7fff95109618  
0x7fff942f3206  0x7fff942f318a  0x7fff942f3148  0x7fff9448699d 
0x7fff94486b2a  0x7fff944870df  0x7fff942bf6d4  0x7fff942bf16d  
0x7fff942f0b9b  0x7fff950d1694  0x7fff950d11e6  0x7fff950b1ba1  
0x7fff950b1216  0x7fff942924ff  0x7fff94299c21  0x7fff94299aae  
0x7fff9551b191  0x7fff9551aa95  0x7fff955173d6  0x103391e69  
0x103383bd0  0x1
Aug 27 06:32:55 hiiragi-no-MacBook-Pro SecurityAgent[255]: 
[IMKInputSession activate] exception caught.
	IMKInputSession:  -- 
	NSPortTimeoutException : connection timeout: did not receive reply

しかもこれをLittle Snitchを起動していない時間帯もずっと繰り返していることが判明。
どうやらLion導入以来ずっと重いなと感じていた原因のひとつが明らかになったようです。

さっそくLittle Snitchをアンインストールすることに。
いずれは対応するのかもしれませんし、とても有用なアプリだと思いますがとりあえずは環境整備が優先です。
フォーラムを見たところ他にも不具合が出ているようですし、Lion対応はまだ謳っていないようなので、残念ながら外すことにしました。





クラッシュの前の段階をずっと辿っていくとまさにLion導入以来
ずっとLittle Snitchとそのdaemon、システムのSecurityUIagentというプロセスが
悲鳴を上げるように毎秒ログを吐き続けていました
Little Snitchを起動しているかどうかに関係なくです
これじゃシステムが重くなるのは当然です


今回クリーンインストールではなく、実際に仕事機に導入しているような人の環境を想定してインストーラからいきなり上書きインストールをしたわけですが、そうするとこういう問題が起きる可能性があるということです。

Lion導入以来、どうもMacの動作が重くなってしまったという人はdaemon等の動きもチェックしてみるといいと思います。
その方法はやはりこのように地道にシステムログなどをあたっていくのが確実かと思われます。

さらにCPUが頻繁にフルアップする問題にも注目。
アクティビティモニタを起動してその時の状態をチェックするとまた
mds
mdimporter
mdworker

等のプロセスが暴走してます。

これと類似の症状はLeopard導入当時にも体験している。
2007 年 3 月 8 日
原因不明のmdsの暴走が起きた

これが起きるのはバックアップのために外付けハードディスクをつないだ時が多いようですので、原因はこれと特定して対処しました。





例のアンマウントできないボリュームはSpotlightインデックスの初期化をしても
同じ症状が続くのでボリュームを消去、修復しました
これはこのボリューム固有の問題だったようでこれで異常動作は起きなくなりました




さらにシステム環境設定Spotlightに入って
プライバシータブで接続する可能性のあるボリュームをすべて検索除外領域に指定しました
これでスッキリ動作、Spotlightも何故かうまく動いていなかったようなのですが
瘧がとれたように再構築もスムーズにいってCPUフルアップは無くなりました


ということで時々ファンがガンガン回りまくって、システムが重くなるという問題や特に何をしていなくてもSwapが数GBも生成されまくるという問題は解消されたようです。

CPU等の温度がSnowLeopard時代と比べてまだかなり高いという問題は残っていますが、これも何か対処法があるのかもしれません。
そのうち対応します。




2011年8月28日









anchor

「再ログイン時にウィンドウを再度開く」にチェックが入っていても無効にする方法を試してみました

Lionの新機能に不意にログアウト、あるいは強制終了することがあっても「次回ログイン時にウインドウを再度開く」というものが追加されました。

もし必要ない時にはログアウトの時に出てくる「再ログイン時にウィンドウを再度開く」タグのチェックを外せば次回ログイン時に余計なウインドウが開きません。

一見便利そうです。
でも実際使ってみるとウインドウを隠している常駐アプリ、例えば
XBattery
のようなアプリを使っていますので、これが不意のログアウトの度にウインドウの数が増えていっていちいち閉じればいいんですが、何だか手間が増えただけで全然便利じゃない気がしてきました。

次回ログイン時に前に使っていたアプリを使いたい場合はそのアプリを起動すればいいだけだし。

Lionの新機能に関しては礼賛と批判が半々でどちらかというとSnowLeopardと同じに戻して使っている人が多い気がしますが、それだったらアップデートなんかしないでSnowLeopardを使っていればいいぢゃないかと思っています。
なのでできるだけ設定を変えないでそのまま使うようにしています。
が、しかしこの機能だけは慣れることができません。

そこでveadarさんのこちらの記事に従って、この機能を殺して見ることにしました。
「再ログイン時にウィンドウを再度開く」にチェックが入っていても無効にする方法 | Macの手書き説明書

Terminalを起動して以下のコマンドを入力(コピペでOk)すしてEnterです。

curl http://goo.gl/Z4EFC -L -s -o ~/fixlogin.sh && chmod +x ~/fixlogin.sh && sudo ~/fixlogin.sh ; rm ~/fixlogin.sh

パスワードを要求されますので、勿論rootパスワードを。

これは「http://goo.gl/Z4EFC」にあるスクリプトをダウンロードして、ファイルに保存する、さらにfixlogin.shという名前で保存してシェルで実行した後に削除せよというコマンド。

これを実行すると概要のURLから
pastie-2427953.sh
というシェルスクリプトをダウンロードする。

そのスクリプトの内容はこんな感じ。

#!/bin/bash
echo "#!/bin/bash" > /tmp/loginfix.sh
echo "rm /Users/*/Library/Preferences/ByHost/com.apple.loginwindow.*"
 >> /tmp/loginfix.sh
mv /tmp/loginfix.sh /usr/bin/loginfix.sh
chmod +x /usr/bin/loginfix.sh
defaults write com.apple.loginwindow LoginHook /usr/bin/loginfix.sh




コマンドをTerminalで実行
パスワードを求められる


以上で次回ログインから勝手に起動中のアプリを復元しなくなります。
めでたし。

元に戻したい時には

sudo defaults delete com.apple.loginwindow LoginHook

というコマンドを打つだけでOK。





このコマンドを実行するだけでまたログイン時にアプリが復活するお節介機能が復元する
一応なんでも解除の方法を知っとかないとね



2011年9月6日













Previous Topへ Next





site statistics