うちから歩いて３分のラーメン屋「Parade(パレード)」が、（活動休止という表現ですが）本日3月31日でとりあえず店を閉められるということになりました。
古くは中学生時代にバイトしてたシステム屋が潰れ、高校生時代に売り込んだ雑誌が休刊し、就職先が移管され、就任先が合併され、転職先が潰れてフリーの身になった僕としては、けっこう悲しい気分になったのですが、としむねさんの掲示板の情報によりますと、同じ場所で営業を再開することは「確実」ってことだそうなので、ここは感傷的にならないようにしときます。
さっき「ロビン」を頂いて帰るとき、店主が「じゃ、また」と言ったのをはっきり耳に記憶してるので、きっと復活してくれるに違いない！
あ、復活するときは、営業時間をもっとちゃんと守ってね(笑)
今日の猫村さん3
ほしよりこ
1200円
1日1コマで連載しているほしよりこの大人気エンピツ漫画第3弾。…このハマリっぷりは尋常じゃないってくらいハマってます。
そんな派閥があるのかはわからないけど、TVドラマよりはダンゼン猫村ねこのが面白い派。
石崎秋子より猫村ねこです。
へうげもの６
山田芳裕
540円
織部ってよさげだけど高いし庶民にはかんけーねーよな。
ってのがこのマンガのおかげでぐっと身近に感じられるようになりました。
「デカスロン」を読み返したくなったので今度「あがりゃんせ」で読みます(笑)
ここで「俺は『大正野郎』のコミックを持ってる」とかいうと、オタクっぽいので黙っておきます。
photo credit: dreamyshade
毎日自動でdel.icio.usブックマークが投稿されるdaily blog postingですが、どうも3月26日から止まってるとしか考えられません
たまたまブックマークしてない日と重なったので確信するのに時間がかかったのですが、僕のアカウントのdaily blog posting設定ページでは、
results:Running at Tue Mar 25 15:24:01 2008 GMT<br>Fetched 0 items.<br>
と、25日から動いてない模様
もしかして、ブックマーク0個の日があると、そこで止まっちゃうのかな？
と思ったけど、3月21日は無しでも22日にはちゃんと出来てるし・・・12日も14日も抜けてるし・・・
まぁ設定ページにもThis experimental featureなんて書いてあることだし、とりあえず気にしないでメモがわりに記事だけ書いときます
PostgreSQLの8.3に対応のLudiaの1.5がリリースされたのですが、8.3で利用するとvacuum非対応になり、vacuum後はREINDEXが必要になっていましました。
これは8.3でのHOTがらみの変更で、以前と同じ仕組みだと対応できないということなのでとりあえずは仕方ないのですが、運用上はなんとか対応する必要があります。
ひとつはautovacuumをoffにして運用する方法です。
もうひとつは、Ludiaのインデックスを使用しているテーブルだけautovacuumの対象外にして運用する方法です。
どちらにしても、Ludiaのインデックスはvacuum実行後にreindexを行う必要がありますが、Ludiaのインデックスを使用しているのは一部のテーブルのみという場合、そこだけautovacuumの対象外にして、（たとえ、それがスクリプトの仕事だとしても）定期メンテナンスを行うのが楽です。
特定のテーブルをautovacuumの対象外にするには、以下のようにシステムカタログpg_autovacuumにレコードを作成します。
まず、テーブルのpg_class.oidを調べます。
ryo=# select oid,relname from pg_class where relname = 'groups';
oid | relname
-------+---------
19123 | groups
(1 row)
pg_autovacuum.enabled=falseとしてレコードを作成します。
ryo=# insert into pg_autovacuum values (19123, false, -1, -1, -1, -1,
-1, -1, -1, -1);
INSERT 0 1
Time: 88.973 ms
autovacuumとpg_autovacuumについてはドキュメントの
23.1. 定常的なバキューム作業 - 23.1.4. 自動バキュームデーモン
44.10. pg_autovacuum
を参考にどうぞ。
photo credit: trekkyandy
このサイトをホスティングしてるサーバーでは、CentOS5を使っている。
そのCentOS5に入ってるログ監視ツール「logwatch」からのメールが、ちゃんと届かなくなってしまった。
仕組みとしては、朝４時に動くcron.dailyスクリプト郡の一番手になっている
/etc/cron.daily/0logwatch
が、
/usr/share/logwatch/scripts/logwatch.pl
へのリンクになっていて、ログ監視ツールが起動される。
本来ならこれでちゃんとしたレポートがメールで届くはずなんだけど、届くメールでは、
postdrop: warning: uid=0: Illegal seek
sendmail: fatal: root(0): queue file write error
なんて書いてあるだけで、ログ監視の意味がなくなっていまっているのだ。
このメッセージはちょっとわかりにくいんだけど、どうやらpostfixでメールの容量制限に引っかかってしまっている模様。
postfixでのメールサイズの制限は、message_size_limitで指定でき、デフォルトは10240000=10Mとなっている。
/etc/postfix/main.cfで
message_size_limit = 51200000
としてpostfix再起動後、/etc/cron.daily/0logwatchを動かすと、ちゃんと届きました。
それにしてもログ監視のメッセージが10Mを超えるなんて、とんでもない時代というか、とんでもない事態というか・・・
sshのブルートフォースアタックと、SMTPでspammerを弾いてる数がやたら多いのが原因です。
