今回の秋の連休は有休も使って9連休にしていました。
休み明けのボケた頭では仕事にならないので、午前中は開発用サーバたちのパッケージのアップデートをしていたところ、その中の1つにログインできませんでした。
そのホストは OpenSolaris 2009.06 の中に立てた Linux Branded Zone(BrandZ と書いた方がいいのかな)にインストールした CentOS3 でした。Solaris の Zone なので、ホストOS の方からは自由に Linux のファイルシステムに入っていけます。中のファイルを調べたところ、ログファイルの1つが46GB以上に肥大化してしまってディスクの残り容量が無くなってしまっているのが原因のようでした。
これなら、巨大化したログファイルを削除すれば問題解決だな、と軽い気持ちでrm ログファイル を実行したところ、意外な結果が戻ってきました。
cannot delete file: no space left on device.
ディスクに空き領域が無いからファイルを消したいのに、空き領域が無いからファイルを消せないと言われても。。。
Read More
今月の頭にお客さんに収めたサーバ機のハードディスクが1週間で壊れたので、急遽ディスクのリプレースに行ってきました。今回のシステムは Linux の Software RAID で 2 本のディスクを使用して RAID1 を組んでいたのでデータ自体は無事だったのですが、手を離れたと思った瞬間のトラブルは心臓に悪いですね。
めったに行わない作業なので、自分用にメモ。
Read More
2006年頃に Rails 1.2 で作成したアプリケーションを Rails 2.3 にアップグレードしています。
プログラムの移行自体は1週間ほどで完了したのですが、テストをしていてタイムゾーン関連の問題に遭遇しました。
データベースに有効期限を表すフィールドがあるのですが、1時間前から1時間後まで有効なレコードを作成して、現在が有効期間内かどうかを調べるテストが失敗したので問題に気がつきました。
Rails 2.x ではタイムゾーンが導入されたのは知っていたので、下のように設定を行っていました。
config.time_zone = 'Tokyo'
config.active_record.default_timezone = 'Tokyo'
しかし、ログを見ていると JST と UTC とタイムゾーンが混ざっているようだったので、単純なアプリを作成して調べてみました。すると、以下のような結果に
c = Sample.find(:first)
>> c[:created_at]
=> Mon, 24 Aug 2009 17:09:49 +0000
>> c.created_at
=> Tue, 25 Aug 2009 02:09:49 JST +09:00
>> c[:created_at].class
=> DateTime
>> c.created_at.class
=> ActiveSupport::TimeWithZone
同じフィールドでも [] メソッドでデータを取得するのと、フィールド名を指定して取得するので、クラスもタイムゾーンも異なるんですね。ちょっとビックリしました。
どこかにタイムゾーンを意識しないコードがあって、この2つを混同してしまってるんだろうな。
調べるのはメンドクサイな。
前回の記事で問題となっていた、DVDの不良は週明けに渋谷のアップルストアに行って交換してもらいました。店員さんもなれた感じの対応でしたので、同じような返品交換がけっこうあったんでしょうね。「交換用の DVD もアップルストアで中身を開封して確認したわけではないので、これにも不具合が絶対に無いとは言いきれない」のような事を言っていたのでは、ある意味正直な店員さんだったんだろうな。
新しい DVD で再インストールしたところ、それまで起動できていなかった Mail, iPhoto, QuickSilver などは正常に使えるようになりました。普段使っているアプリに関しては(いくつか対応待ちのものがあるものの)移行は問題ないかと思っていましたが、昨日FreeMindが動かないのに気がつきました。仕事の議事録等は FreeMind で書くのが習慣となっていたので、このアプリが動かないとけっこう困ります。
Read More