2012-10-31

Animes in the 3rd quarter of 2012

アニメは IT エンジニアの必須科目です。 ということで簡単なレビューを。

前期は面白く無かったのに、第二期が始まってしまった。何とか面白いこと言おうと一生懸命なのは伝わってくるが、殆ど空回るので見てて痛々しい。ただ、黄・紫・メガネの掛け合いは良かった。ていうか「コミック百合姫」とかあるんですか? つくづく日本人って凄いと思う。確かに女子しか出てこないし、タイトルの意味もよく分かった。

最初はどうなることかと思ったが、我慢して見てたら後半は普通に見れた。キャラ付けもできてると思うし、意外なことに AKB が当てている声も慣れればそれっぽく聞こえた(一部を除く)。ただ、それなら襲名メンバーにプロ声優を当てたのが中途半端だと思う。突っ込み所を数えれば切りが無いが、結果としてこれはこれでアリだった気がする。

最初の一人目、幼馴染とはいえ、さっきまでの敵同士が手のひら返して「オレたち親友」とか言ってる所からもうダメだった。その後も仲良しごっこ、恋愛ごっこ、主人公のコンプレックス丸出し言動など、色々とイタいところが多すぎる。せっかく世界観はなかなか良いと思うのに、脚本で全てが台無しになるという良い例だった。

主人公がイライラするのは前作と同様。個人的にはエレナがツボったが、エウレカスイッチでヒステリーになるのが残念。前作もそうだったが、このシリーズはヒステリー持ちが多くて楽しくない。全体的な点としては、エウレカの存在感が大きすぎて今作キャラがすっかり霞んでしまった感がある。寧ろエウレカは出さない方が良かったのでは。

前回はイマイチだったが、今回も同様。ロボットものなのに途中からロボットに乗るの放棄するし、いったい何処に向かっているのか。敵味方が行使する力の理屈も世界観もさっぱり伝わってこないので、楽しむものがキャラくらいしか無い。しかしキャラの魅力も今ひとつなので詰んでる。絵は綺麗なだけに、色々と勿体ない作品だった。

基本、一話毎に新キャラが出るので、キャラを覚えられない。これは構成のミスだと思う。数あるキャラでは、秀吉がお気に入り。米を食って幸せ一杯の「ウマー」にやられた。声が名塚佳織というのも意外で良かった。少年サンデーでも短期連載があったが、両者の中身は全くの別物。笑えるという意味では漫画の方が勢いがあって良かった。

前作に引き続き、話がさっぱり分からない。もうこれは「要、予習・復習」とかいうレベルではなく、これがカッコイイと勘違いしているのでは。せめて重要そうな「歴史再現」の説明はもっと kwsk。訳の分からなさは徹底しているので、後はキャラを楽しむだけ。もう少しビギナーへの配慮が欲しかった。普通は Wikipedia とか読まないからね。

サンライズにしては絵がチャチく感じる。チラ見した限りは原作の方が綺麗に見える。中身は典型的なドタバタ劇で、花澤香菜(ヒロインの中の人)の頑張りが伝わってくる。が、それでも枠の中に収まっている感が否めない。他作品と比べるのは良くないが、同じサンライズとして銀魂・SKET DANCE くらいを期待してしまうのは酷だろうか。

主人公は苦もなく強力な力を手に入れる -> 強いのでモテる、というご都合ハーレム展開。一応、神々との戦いでは何か理屈が働いてるっぽいのだが、神話マニアじゃないから良く分からん。取り巻きに好みさえ居れば、まあ見れる。私は青い人(喜多村英梨)が真ん中だったので無問題だった。もし続きがあれば、青い人目当てで見ると思う。

武将を女子化するのはもういい加減に食傷ぎみだが、絵は好みの部類。しかしヒロインが大してイケてない主人公にデレるとか、ぜんぜん信長っぽくない。史実の改変を許容しているので、話もどうしてもご都合展開になってしまう。加えて主人公は典型的な「気持ち」だけの人で努力の描写が欠如している。残念だが私には楽しむのは無理だった。

視聴前の印象よりは良かったが、その後の期待には及ばなかった感じ。個人的には第二話がピーク。合唱がテーマの割には合唱シーンが少ない。その合唱も全員が同じパートを歌うのではなく、少なくとも(キーが異なるのだから)男女でパートを分けた歌をもっと聞きたかった。と細かい不満を言いたくなるくらい、個人的には惜しい作品。

果たして「超訳」は言い過ぎだったと思うが、まあ確かに今風のノリとツッコミでアレンジされている。ワクワクする面白さは無いが、退屈することもない。逆に、百人一首に思い入れがあると受け付けないかも知れない。ところで毎度こういうのを見るにつけ、つくづく人間って千年経っても 1 ミリも進歩してないんだなあと実感する。

原作はどうもに読む気にならないが、アニメ版は素直に面白かった。テンポが良いのと、何より白石涼子(姫子)の力が大きい。何でこの人はこんなにも方言キャラにハマるのだろうか。もし別の声優が当たっていたら、今よりずっとつまらなかったと思う。後釜は「銀魂」とのことで、銀魂 -> SKET DANCE の無限ループが見えた気がする。

アサルトライフルを女子化とか誰が考えた。挙句に「T バック」とか「撃鉄落ちちゃう」とか、バカじゃねーの? もう、同じ日本人として誇りに思うよ:-D。メインキャラには萌えなかった(高等部の方が良かった)が、その他でお腹一杯になったので良し。ライフルへの愛が伝わってくる作品ではあるが、一般人にはなかなか勧められない作品。

前期は未見、原作は既読。そのせいかも知れないが、これはアニメ化する意味があったのだろうか。本作の魅力は女子キャラと発酵のうんちくだと思っているが、アニメになったせいで後者が著しく損なわれてしまった。かといって前者が立っているかというと、何か声優がミスマッチのような気がするし。まあ原作の復習としては丁度良い感じ。

少女マンガ原作だが、結果はイマイチ。まず個人的な好みの問題として、ヒロインに萌えなかったのが大きい。そして中盤から主人公が精神世界に行きっぱなしになり、ずっと支離滅裂な世界を見せられた後、現実に戻ったらハッピーエンドを通り越してお葬式。って感情移入する暇が全く無いんだけど。原作もこうなの? ただ ED は良かった。

やっぱり「ガンダム」の冠は重いよね、という予想通りの結果。AGE の意味が分かったときには新鮮な驚きはあったが、親子三代はやり過ぎだろう。作風から低年齢が主なターゲットに見えるが、ガンダムファンはみんな高年齢なので評価されるのは難しいと思う。とはいえ SEED の例もあるし、そのうち当たりもあるだろうと次に期待。

前作に続き視聴。キャラは倍に増えたが、話はますます暗くなった。どいつもこいつもコンプレックスの固まりで、見てるこっちが陰鬱になってしまう。パズルの楽しさは何処にいった。あと、やっぱり個人的に萌えるキャラが居ない。エレナは相変わらず出番が少ないし。何を思ったか更に 3 期に続くようだが、このままでは期待できる要素が無い。

ジャンプのスポーツ漫画らしく、必殺技がデフォルト。まだ本作は人間の範疇に見えなくもないので我慢できるが、そのうち影分身とかするようにならないか心配。必殺技に目をつむって人間関係だけを見れば、普通に面白いと思う。個人的には、もっと(本作にも無い訳ではないが)正しい努力の積み重ねが結果に結びつくという描写が欲しい。

思わず見とれてしまう程の、絵の美しさ。これだけでも見る価値はある。話の方はグッとくる面白さは無いが、地味に面白い。絵のせいもあり独特な雰囲気があるので、深夜にしんみり雰囲気に浸って見るのがお勧め。個人的には色々と納得いかない推理も多かったが、それはきっと私がバカだからだろう。あと、1st OP は良かった。

OP や初話のノリで期待して見ると、実は結構な重い話に裏切られる。各キャラが個々のイベントにマジレスし過ぎ。そりゃ本当に人格が入れ替わったら大変だよ。心を壊す輩も出てくるさ。しかしその葛藤をアニメにする意味が分からん。ハッピーエンドになるのは分かってるが、道中もハッピーにして欲しかった。キャラが魅力的なだけに残念。

しかしこう書き連ねてみると、いい加減にアニメ見過ぎだな。もう少し絞らないと時間がいくらあっても足りない。しかしアタリかハズレかなんて見ないと分からないしなあ。

2012-09-24

RHEL6: multi NICs in the same subnet

タイトルは「NIC」としているが、どちらかと言えば「インターフェイス」の意味。要は複数 LAN ポートを同一サブネットに繋ぎたい。

例として、次のように設定する。

  • eth0: 192.168.1.11/24 (00-0c-29-11-11-11)
  • eth1: 192.168.1.12/24 (00-0c-29-22-22-22)

このとき双方に ping を打つと、実際には eth0 だけが応答する。

>ping 192.168.1.11
>ping 192.168.1.12
>arp -a
インターフェイス: 192.168.1.101 --- 0xc
  インターネット アドレス      物理アドレス      種類
  192.168.1.11          00-0c-29-11-11-11     動的
  192.168.1.12          00-0c-29-11-11-11     動的

これは Linux ネットワークの仕様。RHEL5 だと、次を設定することで両方から ping が返るようになる。

net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
>ping 192.168.1.11
>ping 192.168.1.12
>arp -a
インターフェイス: 192.168.1.101 --- 0xc
  インターネット アドレス      物理アドレス      種類
  192.168.1.11          00-0c-29-11-11-11     動的
  192.168.1.12          00-0c-29-22-22-22     動的

しかし、RHEL6 で同じ設定をしても動かない。具体的には、eth1 への ping が返ってこず、ARP テーブルにも登録されない。

>ping 192.168.1.11
>ping 192.168.1.12
>arp -a
インターフェイス: 192.168.1.101 --- 0xc
  インターネット アドレス      物理アドレス      種類
  192.168.1.11          00-0c-29-11-11-11     動的

この理由がずっと分からなかったが、どうやら RHEL6 から rp_filter の挙動が変わったようだ。結論から言うと、次の設定で RHEL6 でも動くようになる。

net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.rp_filter = 2

理由はこの辺りを参照。

RHEL5 では、conf.all.rp_filter と conf.<interface>.rp_filter との論理積(AND)が rp_filter の実効値だったが、RHEL6 では最大値(MAX)が実効値になった。

RHEL5 / RHEL6 のどちらにも、/etc/sysctl.conf に次の設定がある。

# Controls source route verification
net.ipv4.conf.default.rp_filter = 1

よって RHEL5 の場合、rp_filter の値は次のようになる。

[rhel5]# sysctl -a | grep '\.rp_filter' | sort
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.eth1.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 0

rp_filter の実効値は、eth0 であれば all.rp_filter AND eth0.rp_filter (=0)となり、eth0 の rp_filter は無効となる。つまり /etc/sysctl.conf にそれらしい設定がありながら、実は 全く効いていなかった ということ。騙された。

RHEL6 の場合は、

[rhel6]# sysctl -a | grep '\.rp_filter' | sort
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.eth1.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 1

今度は MAX(all.rp_filter, eth0.rp_filter) (=1)となり、rp_filter は有効となる。RHEL5 と全く同じ動作にしたいなら、/etc/sysctl.conf で net.ipv4.conf.default.rp_filter = 0 と設定する必要がある。

今回の目的(同一サブネットに複数インターフェイス)では、rp_filter = 2 にすれば良い。これは loose mode というらしく、いずれかのインターフェイスから到達可能な宛先であればパケットを受信する、というモードのようだ。RFC3704 なんて読む気ないので詳しくは知らない。

そもそも今回の件で rp_filter が影響することが分かり辛いが、極力プライマリインターフェイスで通信しようとする Linux の特性を考えると、何となく理解できなくもない。今回の場合、プライマリ側である eth0 が ARP パケットを処理する際に rp_filter が効くのだろう(と思う)。が、やはり Linux のこの特性は分かりにくい(直感的でない)と思う。

以上のように、Linux で複数インターフェイスを同一サブネットに繋ごうとすると、非常に微妙な領域に足を突っ込むことになる。やるなら 1 個のインターフェイスに仮想 IP アドレスを付ける方法(仮想インターフェイス)をお勧めする。じゃあ私は何故そうしないのかと言うと、現場 SE に「仮想 IP アドレス」とか言っても通じないから。少なくとも自力で設定できるとは思えない。しかし「1 つの LAN ポートに 1 つの IP アドレス」であれば、彼等にも理解してもらえる確率がグッと上がる。:-)

2012-09-02

Tomcat: Cannot stop in wrong hosts configuration

あるサーバーだけ、Tomcat の停止に失敗する。

2012/08/29 15:56:51 org.apache.coyote.http11.Http11Protocol pause
情報: Coyote HTTP/1.1を http-8080 で一時停止します
2012/08/29 16:00:00 org.apache.catalina.connector.Connector pause
致命的: プロトコルハンドラの一時停止に失敗しました
java.net.ConnectException: Connection timed out
	at java.net.PlainSocketImpl.socketConnect(Native Method)
	at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
	at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
	at java.net.Socket.connect(Socket.java:529)
	at java.net.Socket.connect(Socket.java:478)
	at java.net.Socket.<init>(Socket.java:375)
	at java.net.Socket.<init>(Socket.java:218)
	at org.apache.jk.common.ChannelSocket.unLockSocket(ChannelSocket.java:492)
	at org.apache.jk.common.ChannelSocket.pause(ChannelSocket.java:288)
	at org.apache.jk.server.JkMain.pause(JkMain.java:726)
	at org.apache.jk.server.JkCoyoteHandler.pause(JkCoyoteHandler.java:153)
	at org.apache.catalina.connector.Connector.pause(Connector.java:1064)
	at org.apache.catalina.core.StandardService.stop(StandardService.java:578)
	at org.apache.catalina.core.StandardServer.stop(StandardServer.java:788)
	at org.apache.catalina.startup.Catalina.stop(Catalina.java:662)
	at org.apache.catalina.startup.Catalina$CatalinaShutdownHook.run(Catalina.java:706)
2012/08/29 16:00:01 org.apache.catalina.core.StandardService stop
情報: サービス Catalina を停止します

Tomcat バージョンも示しておくが、多分どのバージョンでも起こる。

[appserver]# service tomcat6 version | grep version
Server version: Apache Tomcat/6.0.35

ちなみにタイトルは「Cannot stop」としているが、正確には上記のタイムアウトに時間が掛かる(3 ~ 5 分)だけで、待ってさえいれば停止する。

最初は、何でシャットダウンするのに socket が timed out するのかと思ったが、自身のシャットダウンポートへ通信しているのではと勘付けば、ネットワークに問題がありそうだと察しが付く。(ソースコードは見てないので、実際のところは知らない)

[appserver]# ifconfig | grep 'inet addr'
          inet addr:172.16.1.10  Bcast:172.16.1.255  Mask:255.255.255.0
          inet addr:127.0.0.1  Mask:255.0.0.0

/etc/hosts:

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1		localhost.localdomain localhost
::1		localhost6.localdomain6 localhost6
192.168.10.12	appserver

案の定、実際の IP アドレス(172.16.1.10)と /etc/hosts (192.168.10.12)が食い違っている。私が試した限り、それぞれが別ネットワーク(サブネット)だと今回のエラーになるようだ。食い違いがあっても、同じネットワークだと起こらない。

/etc/hosts を修正して、ネットワークを再起動すれば解決する。

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1		appserver localhost.localdomain localhost
::1		localhost6.localdomain6 localhost6

所詮、現場 SE の程度なんてこんなもんだ。IP アドレスを変更する際に /etc/hosts に気を払うこともできない。ちなみに今回の場合、上記に加え /etc/resolve.conf も /etc/sysconfig/network もボロボロだったことを付け加えておこう。

そしてこういうことがあるから、特に理由のない限り、自ホスト名は「127.0.0.1」に登録するのが正しい。これについては以前のエントリで述べた通り。

127.0.0.1 ではなくサーバーの IP アドレスで登録すべき、と言われそうだが、それでは DHCP 環境で使えない。固定 IP アドレス環境でも、永遠に IP アドレスを変えないと保証できるはずもない。その際に IP アドレスを変更する SE が、/etc/hosts に気を回すスキルを持っていると期待するほど、私はお人好しじゃない。

2012-08-07

Animes in the 2nd quarter of 2012

アニメは IT エンジニアの必須科目です。 ということで簡単なレビューを。

前作は最初のインパクトが強すぎて以降が霞んでしまったが、今回もその流れのままブレイクには至らず。キャラも順調に増えていっているのに、イマイチ突き抜けられないのは何故だろう。更に続きそうな終わり方だったが、次回があっても期待薄か。ただ、毎話末にある妄想ユウ劇場は良かった。ED も、悔しいけど好き。

元ネタを知らないので、暫くは女子向けだと気付かなかった。しかしそれを差し引いても何が面白いのかサッパリ分からんかった。これって女子が見ても面白いの? ヒロインもヒーロー(イケメン)もひたすら弱いし、最後の逆転もインチキっぽいし。良かったのは OP だけだった。

この作品の失敗は 2 つ。1 つは OP にオバさんを使ったこと。まずここで拒絶反応。素直に沢城みゆきで良かった。もう 1 つは作風を劇画調でシリアスにしたこと。ルパンといったらビビッドカラーのコミカルに決まってる。原作派には寧ろ原作に近いと高評価だったみたいだが、殆どの人はアニメのルパンしか知らないから。

前作は何処か野暮ったく、それが作品の独特な雰囲気だったのだが、今作はすっかりオシャレになってしまった。悪く言えば普通になった。相変わらず普通じゃないのは男女合体と曲(菅野よう子)。但し個人的には、前作の主題歌のインパクトは超えられなかった。あと、総司令の「全てお見通し」感がウザいのも相変わらず。

OP が Kalafina だったのでよく見たら、前作(第一期)から音楽が梶浦由紀。OP/ED を聞いてつくづく思うのは、See-Saw のボーカルの人は偉大だったな、と。特に ED は彼女が歌っていれば神曲になったに違いない。中身の方は、正直なところ前作の方が楽しめた。元ネタに思い入れがあれば、また違う結果になったかも知れない。

前作は不勉強ながら未見。前作の英雄が上官になって部下を指導とか、DESTINY でヘタれたアスランを髣髴とさせる。その「ヘタれ」はリミッターにより正当化されているが、それが「新キャラの成長」と「前作キャラの活躍」のどっちつかずを生んでしまった気がする。いっそ新キャラメインに割り切った方が良かったのでは。

少女マンガ原作にしては、ジャズとか時代設定とか渋い。しかも音楽が菅野よう子。私はジャズのことはさっぱり分からないが、彼女の懐の深さには舌を巻く。加えて、YUKI・秦基博に曲を提供とかやり過ぎじゃね? 肝心の話の方は良く纏まっていると思う。終わりも綺麗だったし。ただちょっと綺麗すぎたという感もある。

なかなかオリジナリティーの高い作品。それを認めつつ、宇宙人設定を差し引いたとしても、ハルのズレた性格がどうにも好きになれなかった。あとコンプレックス主人公も。彼等さえ受け入れられたら、もっと高評価だったと思う。OP も良かったし、「ダック」の決めポーズもぶっちゃけ好きだ。

今期一番の伏兵。ヒロインがかなり個性的だが、頼もし過ぎる仲間の存在とで見事にバランスしている。ヒロインの中の人(伊藤静)には最初こそ違和感を感じたが、結果的にはハマり役だったと思う。早々に第二期が確定したが、それも当然か。寧ろこれだけ面白いのに何で最初から 24 話で作らなかったのかと言いたい。

インパクトは今期一番。OP は一度は聞くべき。もう初話からから飛ばしまくりで、途中で息切れしないか見てるこっちが心配になる。好き嫌いは分かれそうだが、ネタとして見ておくことを推奨。私はクトゥルーは知らないが、他にもパロディーネタが多く、分からない台詞を調べたりしてなかなか勉強になった :-)。

Sphere のために企画・製作されたらしい。サンライズだし絵も綺麗だが、万人受けは難しいか。私は結構好きだったが、それは私が年をとり過ぎたせいで、彼女たちの過ごす時間に羨望の情を抱いたせいだろう。逆に若い世代にはちっとも面白くない可能性がある。Sphere は初めてまともに聞いたが、OP はかなり良かった。

最近のアニメっぽくない古風な絵柄だが、直ぐにそれ以上のインパクト(涎)で掻き消される。絵にはそのうち慣れる、というか色気さえ感じるようになる。涎に限らずヒロインは変態だが、それを受け入れられれば後は普通のうぶな恋愛物語。というかこの作品から変態を取ったら何も残らないので、この作品に限っては変態は正義。

一部で前評判が高いので何かと思ったら、何か原作者がそこそこ有名らしい。まずパッと見で全く期待してなかったが、世界観はなかなか独特。ただ全体を通して「ヒロインにイイ格好させたい」臭が鼻に付く。難題が発生しても結局ヒロインが一人で解決してしまうので、逆につまらなく感じる。もっと年相応にデキない子でいいのに。

サイドストーリーにしては、色々と前作に依存し過ぎているような気がする。逆に前作を見ていれば、色々とニヤニヤしながら楽しめる。ただ問題は、余りに短い。なぜ最近のアニメは続きをやるの分かってるのに 12 話で作るのか。どんな理由があったとしても、試合の途中で話を切って良いはずが無い。

前作は特に面白いとは思わなかったのだが、第二期が始まってしまった。相変わらずマイペースでのっぺりした印象。前作でも思ったが、これは男女どちらをターゲットにしているのだろう。掲載誌から考えると男だが、男子が見るには退屈すぎる。どちらかというと女子に受けそうな内容のような気がする。

元ネタを知らないのでてっきり冒険ファンタジーかと思ったら、ずっとパンばっかり焼いててビックリした。一応最後の方でバトルがあるが、唐突に始まってアッという間に終わるのでまたビックリ。最後はまたパンを焼いてハッピーエンド。って何これ。これ見て誰が喜ぶのだろうか。唯一、斉藤千和(猫娘)の「にゃー」が素晴らしかった。

2012-07-29

RHEL6.3: rsyslog no longer supports `reload'

自作インストーラーが RHEL6.3 から動かなくなった。調べると、rsyslog reload が失敗している。

[rhel63]# service rsyslog reload ; echo $?
3

上記には、「rsyslog は reload をサポートしなくなったから代わりに restart を使ってね」とあるが、それだけ言われても釈然としない。しかし実は、以前から身近なところに答えはあった。

[rhel62]# man rsyslogd

SIGNALS
       <...snip...>

       HUP    This  lets rsyslogd perform close all open files.  Also, in v3 a
              full restart will be done in order to read changed configuration
              files.   Note  that  this means a full rsyslogd restart is done.
              This has, among others, the consequence that TCP and other  con-
              nections  are  torn down. Also, if any queues are not running in
              disk assisted mode or are not set to persist data  on  shutdown,
              queue  data  is  lost. HUPing rsyslogd is an extremely expensive
              operation and should only be done when actually necessary. Actu-
              ally,  it  is a rsyslgod stop immediately followed by a restart.
              Future versions will remove this restart  functionality  of  HUP
              (it  will  go  away in v5). So it is advised to use HUP only for
              closing files, and a  "real  restart"  (e.g.  /etc/rc.d/rsyslogd
              restart) to activate configuration changes.

何か未来を予見してたような manpage 出た。「HUP で設定を再読み込みする機能は v5 から無くなるんだからね!」とのこと。どうやらこれは今更の話ではなく、rsyslog かねてよりの固い意志だったらしい。HUP 時に設定を再読み込みする $HUPisRestart という設定項目も、v5 になって消えたようだ。

The $HUPisRestart directive is supported by some early v5 versions, but has been removed in 5.1.3 and above.

ちなみに RHEL6.2 → RHEL6.3 でパッケージバージョンを比べると、

[rhel62]# rpm -q rsyslog
rsyslog-4.6.2-12.el6.x86_64
[rhel63]# rpm -q rsyslog
rsyslog-5.8.10-2.el6.x86_64

同じ RHEL6 中でパッケージのメジャーバージョンが上がるのって反則じゃね? 全ての元凶はここにある気がするのだが。

ともかく、ここに至ってようやく前述の Bugzilla での議論が理解できる。

reload: reload the configuration of the service without actually stopping and restarting the service (if the service does not support this, do nothing)

reload の定義は、「サービスを再起動することなく設定を再読み込みする」となっている。つまり、もはや rsyslog v5 の initscript には reload を実装する術がない。reload をサポートしなくなったというより、サポートできなくなったのだ。だから reload は未実装となり、これまでの流れを考えると、恐らく今後も復活することはないだろう。

結論として、rsyslog に関しては(どんなに不満でも)以下を受け入れるしかない。

  • ファイルハンドルを閉じたいなら HUP シグナル。(kill -HUP <PID>)
  • 設定を再読み込みさせたいなら再起動。(service rsyslog restart)

2012-07-24

Emacs 24: Gnus: `smtpmail-auth-credentials' was removed

いつの間にか Emacs 24 がリリースされていたので、好奇心で使い始めた。Emacs 23 での設定をそのまま引き継いだが、問題なく動く。楽勝じゃん! て調子で仕事してたら、その日の終わりにメールが送れなくなってることに気が付いた。orz

具体的には、Gnus でメール送信時に「SMTP user name for <HOSTNAME>:」って聞かれる。何でこんな基本的なところが動かなくなるんだよ、と恨めしく思いながら調べると、これだ。

** SMTPmail

*** SMTPmail now uses encrypted connections (via STARTTLS) by default
if the mail server supports them.  This uses either built-in GnuTLS
support, or the starttls.el library.  Customize `smtpmail-stream-type'
to change this.

*** The variable `smtpmail-auth-credentials' has been removed.
By default, the information is now stored in the file ~/.authinfo.
This was the default value of smtpmail-auth-credentials.  If you had
customized smtpmail-auth-credentials to a list of user names and
passwords, those settings are not used.  During your first connection
to the smtp server, Emacs will prompt for the user name and password,
and offer to save them to ~/.authinfo.  Or you can manually copy the
credentials to ~/.authinfo.  For example, if you had

  (setq smtpmail-auth-credentials
        '(("mail.example.org" 25 "jim" "s!cret")))

then the equivalent line in ~/.authinfo would be

  machine mail.example.org port 25 login jim password s!cret

See the auth-source manual for more information, e.g. on encrypting
the credentials file.

*** The variable `smtpmail-starttls-credentials' has been removed.
If you had that set, you need to put

  machine smtp.whatever.foo port 25 key "~/.my_smtp_tls.key" cert "~/.my_smtp_tls.cert"

in your ~/.authinfo file instead.

smtpmail-{auth,starttls}-credentials は無くなったので代わりに ~/.authinfo を使え、と。しかもデフォルトで TLS にまで対応してくれちゃうらしい。TLS は使ってないので知らないが、~/.authinfo の方は作ったらサクッと動いた。

しかしこれ、みんな知ってるんかな? 検索しても目ぼしいものが出てこないけど。まあ、Gnus 使ってる人はこれくらい自己解決してるのが当たり前、ということなんだろう。

2012-07-22

Upstart + runit: stop: Job failed while stopping

Upstart で管理している runit を終了させると、エラーが発生。

# stop runsvdir ; echo $?
stop: Job failed while stopping
1

/var/log/messages には、

Jul 17 12:13:38 rhel6 init: runsvdir post-stop process (3686) terminated with status 1

どうやら post-stop 処理がエラーになった模様。runsvdir の Upstart 設定は次の通り。

/etc/init/runsvdir.conf:

# for runit - manage /sbin/runsvdir-start
start on runlevel [2345]
stop on runlevel [016]
respawn
exec /sbin/runsvdir-start
post-stop exec pkill -x runsv

実際、pkill はプロセスが見つからない場合に 1 を返す。どうせここで pkill が失敗したところでどうしようもないし、post-stop を次のように変更して対処した。

post-stop script
	pkill -x runsv || true
end script