2015-11-30

RHEL7: Old PostgreSQL's initdb fails

下記の環境にて、PostgreSQL 8.4.17 をビルドする。

# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.1 (Maipo)

# rpm -q gcc
gcc-4.8.3-9.el7.x86_64

initdb でエラーが発生。

# su - postgres -c "/usr/local/pgsql-8.4.17/bin/initdb -E UTF8 --no-locale -D ./data" ; echo $?
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale C.
The default text search configuration will be set to "english".

creating directory ./data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 32MB
creating configuration files ... ok
creating template1 database in ./data/base/1 ... ok
initializing pg_authid ... FATAL:  wrong number of index expressions
STATEMENT:  CREATE TRIGGER pg_sync_pg_database   AFTER INSERT OR UPDATE OR DELETE ON pg_database   FOR EACH STATEMENT EXECUTE PROCEDURE flatfile_update_trigger();

child process exited with exit code 1
initdb: removing data directory "./data"
1

調べると、GCC 4.8 で発生するらしい。

上記では、結局 GCC 4.7 でないと駄目だった模様。他のネット情報を見ても、大体「GCC 4.7 使えよ」的な感じ。しかし RHEL7 DVD には GCC 4.7 が入ってないので、解決策がそれだと(個人的に)非常に困る。:-(

という状況で、駄目元で 8.4 系の最新(8.4.22)を取ってきたら、何事もなく動いた。助かった! :-D

該当の部分は、多分これ。PostgreSQL 8.4 系だと、8.4.18 に入っている。一応、8.4.18 で initdb が動くことは確認した。

現時点で、8.2 / 8.3 の HEAD に対しても同様の修正が入っている。私のように困っている人は、HEAD を落としてくると幸せになれそう。

2015-10-31

Animes in the 3rd quarter of 2015

アニメは IT エンジニアの必須科目です。

赤髪という時点でヒロインに強い個性を期待してしまうのだが、その意味でヒロインはキャラが弱かった。話は癖なく纏まっているだけに、タイトル負けした感が強い。

前期より視聴。キャラの多さには慣れたが、何故に話を暗くするのか。原作ファンはこれで満足しているのか疑問。唯一、安易にポリゴンに逃げなかった所だけは評価する。

三期目ということで視聴。ここから見ると既に纏めに入った感を受けるが、各キャラの個性は十分に感じられた。しかし、未視聴分を見ようという気までは起きなかった。

ヒロインが個性的で見て楽しいが、中の人の演技に依る所が大きい。相対的に、他キャラが弱い。原作は四コマらしいが、見てるとそうは思えず、よく話を纏めたなと思う。

前期より視聴。股間へのダイブはもう慣れた。遅ればせながら、ようやく委員長の魅力が分かった気がする。あと、初話でのキャラの違和感がパなかったが、二話目から直った?

最近増えてきた声優業界ネタ。個人的には勉強になるので歓迎だが、本職の人は心に刺さって見るのが辛いのでは?と心配する。で結局、堀江由衣はユリエホイでいいのん?

ヒロインと中の人、キャラ絵のマッチングが素晴らしい。欲を言えば、他の女子三人にもう少し頑張ってもらいたい。しかし今のままでも十分なので、是非とも次回を希望。

地上最強の好き嫌いはともかく、途中から激しくグダる。たぶん、誰もこの作品に「犯人は誰だ!?」的な要素は求めていないと思う。で早速、次回もグダる予感しかない。

またタイムリープ物か、と食傷気味。主人公もパッとしないし、話も取って付けたような内容。だが妹の話だけは良かった。あれなら私もシスコンになれる自信がある。

まだ私には難度が高かったらしく、萌えられず。終わりまで新キャラペースが落ちず、しかも後半ほど難度が上がるという。一般人への布教としては、少し性急だったと思う。

シリーズ視聴。もういい加減、ダラーズの話は漏れなく盛り下がるのでやめて欲しい。今後、カラーギャングと折原の話は禁止でお願いします。いや割とマジで。

主人公は全能で王様プレイ、カテゴリ的には中二病作品だが、何故か苦痛なく見られた。にしてもアルベドは立ち位置ヒロインだろうに、あの残念キャラは何とかならなかったのか。

  • 俺物語!!

少女マンガ原作のアタリは久しぶり感。藩めぐみの演技パない。女子キャラも総じて魅力的。ところで砂川くんのキャラ付けは、やはり女子は○モが好き、ということで良いのだろうか。

話題になっている理由が分からなかったが、原画をチラ見して察した。たぶん漫画から入った人は「この漫画は凄い!」、アニメから入った人は「よく分かんない」となる気がする。

ここまで直球だと最早褒めて良いレベル。石上静香は間違いなく株を上げた。ところで個人的に会長がエロくて良いなと思っていたら、光の速さでビッチになっていた件。

何やら壮大なコラボレーション企画のようで、設定などは非常に凝っており感心するレベル。が、アニメ化に際して凡作になった模様。設定を文字で語るのはアニメとして手抜きだと思う。

これこそ勉強のために見なければ、と見たら色んな意味で想像を超えていた。これがオリジナルの雰囲気をどれ程反映しているのか分からないが、色々と勉強になった。

当時のリアルタイム世代は、見るだけで感慨深いものがあると思う。私も該当するため評価が難しいが、たぶん思い出補正がないと、クソつまらないような気はしている。

可もなく不可もなく、お気に入りのキャラも居なかったため、個人的に非常に評価に困る。結局この作品は、SF、友情、恋愛、その他の何がウリだったのだろう。

昔に小説を途中まで既読。なのでキャラデザには違和感しかない。特にダリューンはもっと華奢でないと駄目だろう、と。絵も話も、私には小説の劣化版に見えてしまう。

シリーズ視聴。今回は「美々の夏休みデビュー」、これに尽きる。この回だけで見た甲斐はあった。逆にシリアス系とかバトルとか、つまらないのでもうやらなくて良いです。

絵が好みでないというハンディを最後まで挽回することができなかった。その中で委員長は惜しかったが、私が萌えるにはまだ足りない。

今回が初視聴だが、私の時系列的に「世界一初恋」にしか見えない。まんま同じキャラやん? 同じ出版業界やん? でやっぱ BL やん? つまり作者は、野球漫画におけるあだち充(BL 版)だと理解した。

テンプレの寄せ集め感。普段から格好良さげな主人公に、いざという時まで格好良くさせたら、余程のことがない限りつまらなくなるのになぜ気が付かないのだろうか。

まず主人公をミスリードさせる導入。それでも中盤まではまずまずだったが、最後、突然のゴリ押しにぽかーん。これ、やっぱり少年を主人公にすべきだったのでは。

2015-08-31

RHEL7: screen: Window title is annoying

screen 使いが RHEL7 を使った時、間違いなく不満に思うこと。

ウィンドウタイトルが ウ ザ い

無駄に長いし、cd する度に長さがパタパタ変わるし、ディレクトリを潜る度にどんどん長くなるし、そのせいで簡単に横幅が溢れるし、とても我慢できたものではない。何故これが初期設定なのか理解不能。誰か喜ぶ人いるの?

調べると、PROMPT_COMMAND のせいらしい。手持ちの環境でざっと比べると、

CentOS 5.5: /etc/bashrc:

# are we an interactive shell?
if [ "$PS1" ]; then
	case $TERM in

	# <...snip...>

	screen)
		if [ -e /etc/sysconfig/bash-prompt-screen ]; then
			PROMPT_COMMAND=/etc/sysconfig/bash-prompt-screen
		else
		PROMPT_COMMAND='echo -ne "\033_${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}"; echo -ne "\033\\"'
		fi
		;;

CentOS 6.2: /etc/bashrc:

    screen)
        if [ -e /etc/sysconfig/bash-prompt-screen ]; then
            PROMPT_COMMAND=/etc/sysconfig/bash-prompt-screen
        else
            PROMPT_COMMAND='printf "\033]0;%s@%s:%s\033\\" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"'
        fi
        ;;

RHEL7.1: /etc/bashrc:

    screen*)
      if [ -e /etc/sysconfig/bash-prompt-screen ]; then
          PROMPT_COMMAND=/etc/sysconfig/bash-prompt-screen
      else
          PROMPT_COMMAND='printf "\033k%s@%s:%s\033\\" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"'
      fi
      ;;

実は各バージョンで微妙に違った。ともかく、RHEL7 の設定だけは看過できない。暫く考えて、次のスクリプトを配置することにした。

/etc/profile.d/myscreen.sh:

if [ -n "$PROMPT_COMMAND" ] ; then
    case "$TERM" in
	screen*) PROMPT_COMMAND=${PROMPT_COMMAND/\\033*\\033/\\033k\\033} ;;
    esac
fi

(嬉しい)副作用として、.screenrc に下記の設定を入れると、実行中のコマンド名がウィンドウタイトルになる。root でなく一般ユーザーなら、「#」の代わりに「$」を使う。確認はしていないが、RHEL6 以前でも動くはず。

/root/.screenrc:

shelltitle "#|bash"

RHEL7 のこの仕打ちは、tmux 使いの嫌がらせ老兵は去れというメッセージかも知れないが、老兵と言えども消えゆくにはまだ早い。screen であと十年は戦える。

2015-08-03

Animes in the 2nd quarter of 2015

アニメは IT エンジニアの必須科目です。

作者のメルマガは(何故か)購読。てっきり、ゆう医師がおっぱいおっぱい言ってる作品かと思ったら、むしろ医師以外がみんな変態で、「心療内科」的には確かに間違ってはいなかった。

前期に続き視聴。原作を知らない私でも、この辺から「ああ、JoJo だな」と感じる。ただ、あれだけ引っ張った割にはディオとの最終決戦が割と呆気ない。

血闘術には独特のセンスを感じる。中二辺りにはウケが良さそう。ただ戦闘を離れたパートがクソつまらないのと、どうにも主人公が好きになれないのでいまいち乗れない。

前シーズンより視聴。今度はアーチャーが面倒臭い奴になったなと思ったら、「ああ、このオチ聞いたことあるわ」と納得。どうやら私は相当に主人公の性格を受け付けないらしい。

元の四コマをただくっ付けただけなのか、全体的にテンポが非常に悪い。原作を読んだことはないが、これでは原作の持ち味を引き出せていないような気がする。

最初に予想したより随分あっさりした展開。親友同士が戦うという設定上、もっと愛憎渦巻く展開を期待したのに。もっとも今後そうなるのかも知れないので様子見。

長い主人公の回想が終わったと思ったら、どこからか湧いてきた女子たちによる主人公の奪還作戦。エロゲ原作なのにエロもなく、何をどう評価して良いのか分からない。

原作は途中まで既読。ヒロインを始めとする女子キャラの魅力は損なわれずに移植できていると思う。連載は結構長かった気がするが、一クールに収まるとは相当削ったのかも知れない。

仕事を選ばないサンリオが、まさかの萌えの世界に。SD キャラの必然性が最後まで分からなかったが、これで音ゲーを出す未来までは見えた。今回は、稲川英里を覚えた。

最初はヒロインのオヤジっぽさにドン引きするが、見続けていると慣れる。それでも全体的に取って付けた感は拭えない。そもそも何故これをアニメ化しようと思ったのか。

前作は視聴したはずだが殆ど覚えてない。今作はこれといった敵も居らず、ひたすら内輪で馴れ合っているだけの印象。そもそも負かした相手に指南してもらうってどうなの。

悲しい結末を迎えることが分かりきっている設定は余り好きではない。予想したよりはずっと良い話に纏まったが、ともすると鬱になる危うい設定だと思う。

キャラクターはおっぱいの押し売り。正直これを書いてる今も、おっぱい大きかったなー、くらいしか思い出せなくて困る。

前作より視聴。相変わらずの鉄板クオリティ。何も言うことはないので、この調子で続きを頼む。

「例の紐」と聞いて。正直それのためだけの視聴だったが、なにこれ、SAO より余程おもしろい。やはり、主人公が全能なのは作品をつまらなくするのだと再認識。

ぼっち待望の続編。途中がグジるのと終わりが良く分からないのを除けば、全体としては満足。で、これ続くの? ていうか続かないと先が気になるんだけど。

最近やたらタイムリープ物が多いな。本作は前半の伏線を後半できっちり回収できている感じで、もう一回見ようと思えるくらいには優秀。でも OP にしょこたんは要らんかったわ。

2015-07-15

RHEL7: `firewalld' dies at `reload'

firewalld の reload が失敗する。正確には、reload は成功するが、firewalld が死ぬ。しかも死ぬのは決まって二回目の reload で、初回は上手くいく。

# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.1 (Maipo)

# systemctl restart firewalld ; echo $?
0

# systemctl status firewalld ; echo $?
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: active (running) since Wed 2015-07-15 18:12:16 JST; 5s ago
  Process: 4566 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
 Main PID: 4597 (firewalld)
   CGroup: /system.slice/firewalld.service
           `-4597 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

Jul 15 18:12:16 rhel7 systemd[1]: Starting firewalld - dynamic firewall dae.....
Jul 15 18:12:16 rhel7 systemd[1]: Started firewalld - dynamic firewall daemon.
Hint: Some lines were ellipsized, use -l to show in full.
0

# systemctl reload firewalld ; echo $?
0

# systemctl status firewalld ; echo $?
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: active (running) since Wed 2015-07-15 18:12:16 JST; 33s ago
  Process: 4924 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
 Main PID: 4597 (firewalld)
   CGroup: /system.slice/firewalld.service
           `-4597 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

Jul 15 18:12:16 rhel7 systemd[1]: Starting firewalld - dynamic firewall dae.....
Jul 15 18:12:16 rhel7 systemd[1]: Started firewalld - dynamic firewall daemon.
Jul 15 18:12:27 rhel7 systemd[1]: Reloading firewalld - dynamic firewall daemon.
Jul 15 18:12:27 rhel7 systemd[1]: Reloaded firewalld - dynamic firewall daemon.
Hint: Some lines were ellipsized, use -l to show in full.
0

# systemctl reload firewalld ; echo $?
0

# systemctl status firewalld ; echo $?
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: inactive (dead) since Wed 2015-07-15 18:12:53 JST; 3s ago
  Process: 5266 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
  Process: 4597 ExecStart=/usr/sbin/firewalld --nofork --nopid $FIREWALLD_ARGS (code=killed, signal=HUP)
 Main PID: 4597 (code=killed, signal=HUP)

Jul 15 18:12:16 rhel7 systemd[1]: Starting firewalld - dynamic firewall dae.....
Jul 15 18:12:16 rhel7 systemd[1]: Started firewalld - dynamic firewall daemon.
Jul 15 18:12:27 rhel7 systemd[1]: Reloading firewalld - dynamic firewall daemon.
Jul 15 18:12:27 rhel7 systemd[1]: Reloaded firewalld - dynamic firewall daemon.
Jul 15 18:12:53 rhel7 systemd[1]: Reloading firewalld - dynamic firewall daemon.
Jul 15 18:12:53 rhel7 systemd[1]: Reloaded firewalld - dynamic firewall daemon.
Hint: Some lines were ellipsized, use -l to show in full.
3

systemd 経由ではなく、「firewall-cmd --reload」で reload すると問題は起こらない。

# systemctl restart firewalld ; echo $?
0

# systemctl status firewalld ; echo $?
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: active (running) since Wed 2015-07-15 18:13:22 JST; 2s ago
  Process: 5266 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
 Main PID: 5271 (firewalld)
   CGroup: /system.slice/firewalld.service
           `-5271 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

Jul 15 18:13:22 rhel7 systemd[1]: Starting firewalld - dynamic firewall dae.....
Jul 15 18:13:22 rhel7 systemd[1]: Started firewalld - dynamic firewall daemon.
Hint: Some lines were ellipsized, use -l to show in full.
0

# firewall-cmd --reload ; echo $?
success
0

# systemctl status firewalld ; echo $?
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: active (running) since Wed 2015-07-15 18:13:22 JST; 18s ago
  Process: 5266 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
 Main PID: 5271 (firewalld)
   CGroup: /system.slice/firewalld.service
           `-5271 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

Jul 15 18:13:22 rhel7 systemd[1]: Starting firewalld - dynamic firewall dae.....
Jul 15 18:13:22 rhel7 systemd[1]: Started firewalld - dynamic firewall daemon.
Hint: Some lines were ellipsized, use -l to show in full.
0

# firewall-cmd --reload ; echo $?
success
0

# systemctl status firewalld ; echo $?
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: active (running) since Wed 2015-07-15 18:13:22 JST; 39s ago
  Process: 5266 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
 Main PID: 5271 (firewalld)
   CGroup: /system.slice/firewalld.service
           `-5271 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

Jul 15 18:13:22 rhel7 systemd[1]: Starting firewalld - dynamic firewall dae.....
Jul 15 18:13:22 rhel7 systemd[1]: Started firewalld - dynamic firewall daemon.
Hint: Some lines were ellipsized, use -l to show in full.
0

どうやら firewalld の HUP 受信処理に問題がありそうだ。試しに firewalld プロセスに直接 HUP シグナルを送ってみると、現象が再現した。最初の HUP 処理後にシグナルハンドラーを再登録してないっぽい? (ソースコードは確認していない)

以上より、

  • 「systemctl reload firewalld」ではなく、「firewall-cmd --reload」を使うべし。
  • もしくは「systemctl restart firewalld」を使う。(但し確立中の接続は切れるかも知れない)

今後これが修正されるとしても、バージョン依存したくはないので、RHEL7 ではこれを徹底するのが良いと思う。もちろん嫌なバッドノウハウであることは認める。:-(

ググってみると、Red Hat Bugzilla には見当たらなかったが、CentOS の方で報告されていた。本家の方でも待っていればそのうち直ると思われる。


2016-05-31 追記

Red Hat Bugzilla にも登録された模様。

2015-06-28

Makefile: Here document

Makefile にターゲットを色々詰め込んでいくと、ターゲットの一覧をヘルプで表示したくなる。そのようなターゲット help を作るのは簡単だが、毎行 echo するとか毎行末 \ エスケープするとか面倒なことはやりたくない。そうすると次は当然、ヒアドキュメントっぽいの無いの?ってなるが、Makefile 文法解析とヒアドキュメントの相性が悪すぎて正攻法ではどうにもならない。というか私には無理だった。orz

環境変数を使え、と。なるほど、make に文字列を展開させるのではなく、シェルに実行時展開させれば良いのか。そうすれば make による文法解析を回避できる。

Makefile:

export _help_msg
override define _help_msg
Targets:
  compile  Compile and build sources.
  install  Install to the PREFIX.
  clean    Remove all generated files.
  help     This message.
Variables:
  PREFIX   The path to be installed.
endef

help:
	@echo "$$_help_msg"

compile:
install:
clean:
# make help
Targets:
  compile  Compile and build sources.
  install  Install to the PREFIX.
  clean    Remove all generated files.
  help     This message.
Variables:
  PREFIX   The path to be installed.

但しこの方法は環境変数を export する必要があり、子プロセスに影響を与える可能性が残ってしまうのが少し気持ち悪い。あとエディターによって(Emacs とか)は、文字列中に半端なクォート(「'」「"」)があると色付けが破綻する。まあ毎行 echo するよりはマシ、ということで妥協するしかない。

2015-05-21

RHEL7: Set RTC to local time

ようやく RHEL7 を触り始めたので、その辺の話題を。

RHEL7 をインストールした日本人が最初に困るであろうことの一つが、OS 時刻がずれていること。これは RTC (要は BIOS 時刻)が UTC と扱われることが原因。RHEL6 まではインストール時に UTC にするかどうか選択できていたのに、RHEL7 では問答無用で UTC になる。

[rhel7]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.1 (Maipo)

[rhel7]# timedatectl status
      Local time: Fri 2015-05-22 02:04:00 JST
  Universal time: Thu 2015-05-21 17:04:00 UTC
        RTC time: Thu 2015-05-21 17:04:00
        Timezone: Asia/Tokyo (JST, +0900)
     NTP enabled: n/a
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a

[rhel7]# cat /etc/adjtime
0.0 0 0.0
0
UTC

上記で RTC 時刻は日本時刻に合っているが、OS 時刻はそれより 9 時間進んでいる。

まあこれは FAQ なので、ググればすぐに「timedatectl set-local-rtc 1」すれば良いことは分かるし、公式ドキュメントにも記載がある。

[rhel7]# timedatectl set-local-rtc 1

[rhel7]# timedatectl status
      Local time: Fri 2015-05-22 02:04:49 JST
  Universal time: Thu 2015-05-21 17:04:49 UTC
        RTC time: Fri 2015-05-22 02:04:50
        Timezone: Asia/Tokyo (JST, +0900)
     NTP enabled: n/a
NTP synchronized: no
 RTC in local TZ: yes
      DST active: n/a

Warning: The RTC is configured to maintain time in the local timezone. This
         mode is not fully supported and will create various problems with time
         zone changes and daylight saving adjustments. If at all possible use
         RTC in UTC, by calling 'timedatectl set-local-rtc 0'.

[rhel7]# cat /etc/adjtime
0.0 0 0.0
0
LOCAL

これで確かに RTC は local time になる。しかし OS 時刻は進んだままだし、今度は RTC 時刻までもが進んでしまった。恐らくこれは皆が望む結果ではない。少なくとも私は望まない。これを(私が)望む結果にするには、set-local-rtc 時にオプション --adjust-system-clock を使う。(詳しくは、man timedatectl)

[rhel7]# timedatectl status
      Local time: Sat 2015-05-23 02:09:00 JST
  Universal time: Fri 2015-05-22 17:09:00 UTC
        RTC time: Fri 2015-05-22 17:09:00
        Timezone: Asia/Tokyo (JST, +0900)
     NTP enabled: n/a
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a

[rhel7]# cat /etc/adjtime
0.0 0 0.0
0
UTC

[rhel7]# timedatectl set-local-rtc 1 --adjust-system-clock

[rhel7]# timedatectl status
      Local time: Fri 2015-05-22 17:11:04 JST
  Universal time: Fri 2015-05-22 08:11:04 UTC
        RTC time: Fri 2015-05-22 17:11:04
        Timezone: Asia/Tokyo (JST, +0900)
     NTP enabled: n/a
NTP synchronized: no
 RTC in local TZ: yes
      DST active: n/a

Warning: The RTC is configured to maintain time in the local timezone. This
         mode is not fully supported and will create various problems with time
         zone changes and daylight saving adjustments. If at all possible use
         RTC in UTC, by calling 'timedatectl set-local-rtc 0'.

[rhel7]# cat /etc/adjtime
0.0 0 0.0
0
LOCAL

これで(私が)望む結果になった。まあ普通の人は「set-local-rtc した後で時刻を合わせ直すので問題ない」で終了しそうだが。

ところで RTC を local time にすると、上記のようにいちいち Warning が出るようになる。言っていることは分かるが、UTC にすると BIOS 時刻がずれてしまうのが気持ち悪い。

例えばインターネットに繋がっている環境では自動的に時刻同期するので、何も意識せずに RHEL7 を使っている人も多いと思う。そういうシステムでは多分このようになっている。

[rhel7]# timedatectl status
      Local time: Thu 2015-05-21 17:17:31 JST
  Universal time: Thu 2015-05-21 08:17:31 UTC
        RTC time: Thu 2015-05-21 08:17:31
        Timezone: Asia/Tokyo (JST, +0900)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: n/a

OS 時刻は日本時間に合っているが、RTC 時刻は(UTC なので) 9 時間遅れている。システム管理者とは別の SE がハードウェア保守をやっている場合、「毎回 BIOS 時刻を直しているのにまた狂った。このサーバーは変だ!」と騒ぎ出すかも知れない。それ以前、これらを知らなければ RHEL7 を使っている当人でさえ、BIOS の時刻を見る度に「?」ってなるだろう。

ちなみに RHEL5/6 では、UTC を local time にするのに次を使っていた。昔のことなのであまり覚えていないが、当時も私が望む結果にするため、色々と調べた記憶はある。

if grep '^UTC$' /etc/adjtime ; then
    hwclock --hctosys --local && hwclock --adjust --local
fi

これはそのまま RHEL7 でも動くが、「timedatectl status」の表示に反映させるには、systemd-timedated を再起動する必要がある。


2015-08-13(Thu) 追記

ということで、私としては自己解決したつもりだった。ところが!

RTC を local time にすると、OS 起動時にログのタイムスタンプがずれることに気が付いた。

次のように local time になっている状態で、OS を再起動してみる。

[rhel7]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.1 (Maipo)

[rhel7]# timedatectl
      Local time: Thu 2015-08-13 11:47:46 JST
  Universal time: Thu 2015-08-13 02:47:46 UTC
        RTC time: Thu 2015-08-13 11:47:46
        Timezone: Asia/Tokyo (JST, +0900)
     NTP enabled: n/a
NTP synchronized: no
 RTC in local TZ: yes
      DST active: n/a

Warning: The RTC is configured to maintain time in the local timezone. This
         mode is not fully supported and will create various problems with time
         zone changes and daylight saving adjustments. If at all possible use
         RTC in UTC, by calling 'timedatectl set-local-rtc 0'.

[rhel7]# reboot

その時の /var/log/messages の抜粋。

Aug 13 11:48:25 rhel7 systemd: Stopping user-0.slice.
Aug 13 11:48:25 rhel7 systemd: Removed slice user-0.slice.
Aug 13 11:48:25 rhel7 systemd: Stopping Dump dmesg to /var/log/dmesg...
Aug 13 11:48:25 rhel7 rsyslogd: [origin software="rsyslogd" swVersion="7.4.7" x-pid="486" x-info="http://www.rsyslog.com"] exiting on signal 15.
Aug 13 11:48:42 rhel7 rsyslogd: [origin software="rsyslogd" swVersion="7.4.7" x-pid="486" x-info="http://www.rsyslog.com"] start
Aug 13 20:48:34 rhel7 journal: Runtime journal is using 4.6M (max 37.0M, leaving 55.6M of free 366.1M, current limit 37.0M).
Aug 13 20:48:34 rhel7 kernel: Initializing cgroup subsys cpuset
Aug 13 20:48:34 rhel7 kernel: Initializing cgroup subsys cpu
Aug 13 20:48:34 rhel7 kernel: Initializing cgroup subsys cpuacct
Aug 13 20:48:34 rhel7 kernel: Linux version 3.10.0-229.el7.x86_64 (mockbuild@x86-035.build.eng.bos.redhat.com) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC) ) #1 SMP Thu Jan 29 18:37:38 EST 2015
Aug 13 20:48:34 rhel7 kernel: Command line: BOOT_IMAGE=/vmlinuz-3.10.0-229.el7.x86_64 root=UUID=7aa3d286-206c-4938-82ce-cfbc6635c417 ro crashkernel=auto rhgb quiet LANG=ja_JP.UTF-8
<snip>
Aug 13 20:48:36 rhel7 systemd: Starting Switch Root.
Aug 13 20:48:36 rhel7 systemd: Reached target Switch Root.
Aug 13 20:48:36 rhel7 systemd: Started Plymouth switch root service.
Aug 13 20:48:36 rhel7 systemd: Starting Switch Root...
Aug 13 20:48:36 rhel7 systemd: Switching root.
Aug 13 20:48:36 rhel7 journal: Journal stopped
Aug 13 11:48:38 rhel7 journal: Runtime journal is using 4.6M (max 37.0M, leaving 55.6M of free 366.0M, current limit 37.0M).
Aug 13 11:48:38 rhel7 journal: Runtime journal is using 4.6M (max 37.0M, leaving 55.6M of free 366.0M, current limit 37.0M).
Aug 13 11:48:38 rhel7 systemd-journald[90]: Received SIGTERM
Aug 13 11:48:38 rhel7 kernel: type=1404 audit(1439466516.972:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
Aug 13 11:48:38 rhel7 kernel: type=1403 audit(1439466517.276:3): policy loaded auid=4294967295 ses=4294967295
Aug 13 11:48:38 rhel7 systemd[1]: Successfully loaded SELinux policy in 322.882ms.
Aug 13 11:48:38 rhel7 systemd[1]: RTC configured in localtime, applying delta of 540 minutes to system time.
Aug 13 11:48:38 rhel7 systemd[1]: Relabelled /dev and /run in 39.287ms.
Aug 13 11:48:38 rhel7 journal: Journal started
Aug 13 11:48:38 rhel7 systemd: systemd 208 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ)

ある期間だけ、タイムスタンプがずれている。前後関係から、rsyslogd が落ちている間に journald が溜め込んだログのように見える。9 時間戻る(UTC 時刻になる)のならまだ分かるが、9 時間進むというのは頂けない。

一方、RTC が UTC の場合、

[rhel7]# timedatectl
      Local time: Thu 2015-08-13 11:51:56 JST
  Universal time: Thu 2015-08-13 02:51:56 UTC
        RTC time: Thu 2015-08-13 02:51:57
        Timezone: Asia/Tokyo (JST, +0900)
     NTP enabled: n/a
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a

[rhel7]# reboot

今度はタイムスタンプはずれない。(正確には、ちょっとずれるけど大きくはずれない)

Aug 13 11:52:14 rhel7 systemd: Stopping user-0.slice.
Aug 13 11:52:14 rhel7 systemd: Removed slice user-0.slice.
Aug 13 11:52:14 rhel7 systemd: Stopping Dump dmesg to /var/log/dmesg...
Aug 13 11:52:14 rhel7 systemd: Stopped Dump dmesg to /var/log/dmesg.
Aug 13 11:52:14 rhel7 systemd: Stopping Multi-User System.
Aug 13 11:52:14 rhel7 systemd: Stopped target Multi-User System.
Aug 13 11:52:14 rhel7 systemd: Stopping Command Scheduler...
Aug 13 11:52:14 rhel7 rsyslogd: [origin software="rsyslogd" swVersion="7.4.7" x-pid="486" x-info="http://www.rsyslog.com"] exiting on signal 15.
Aug 13 11:52:30 rhel7 rsyslogd: [origin software="rsyslogd" swVersion="7.4.7" x-pid="487" x-info="http://www.rsyslog.com"] start
Aug 13 11:52:23 rhel7 journal: Runtime journal is using 4.6M (max 37.0M, leaving 55.6M of free 366.1M, current limit 37.0M).
Aug 13 11:52:23 rhel7 kernel: Initializing cgroup subsys cpuset
Aug 13 11:52:23 rhel7 kernel: Initializing cgroup subsys cpu
Aug 13 11:52:23 rhel7 kernel: Initializing cgroup subsys cpuacct
Aug 13 11:52:23 rhel7 kernel: Linux version 3.10.0-229.el7.x86_64 (mockbuild@x86-035.build.eng.bos.redhat.com) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC) ) #1 SMP Thu Jan 29 18:37:38 EST 2015
Aug 13 11:52:23 rhel7 kernel: Command line: BOOT_IMAGE=/vmlinuz-3.10.0-229.el7.x86_64 root=UUID=7aa3d286-206c-4938-82ce-cfbc6635c417 ro crashkernel=auto rhgb quiet LANG=ja_JP.UTF-8
<snip>
Aug 13 11:52:25 rhel7 systemd: Starting Switch Root.
Aug 13 11:52:25 rhel7 systemd: Reached target Switch Root.
Aug 13 11:52:25 rhel7 systemd: Started Plymouth switch root service.
Aug 13 11:52:25 rhel7 systemd: Starting Switch Root...
Aug 13 11:52:25 rhel7 systemd: Switching root.
Aug 13 11:52:25 rhel7 journal: Journal stopped
Aug 13 11:52:27 rhel7 journal: Runtime journal is using 4.6M (max 37.0M, leaving 55.6M of free 366.0M, current limit 37.0M).
Aug 13 11:52:27 rhel7 journal: Runtime journal is using 4.6M (max 37.0M, leaving 55.6M of free 366.0M, current limit 37.0M).
Aug 13 11:52:27 rhel7 systemd-journald[90]: Received SIGTERM
Aug 13 11:52:27 rhel7 kernel: type=1404 audit(1439434345.778:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
Aug 13 11:52:27 rhel7 kernel: type=1403 audit(1439434346.070:3): policy loaded auid=4294967295 ses=4294967295
Aug 13 11:52:27 rhel7 systemd[1]: Successfully loaded SELinux policy in 307.437ms.
Aug 13 11:52:27 rhel7 systemd[1]: Relabelled /dev and /run in 39.670ms.
Aug 13 11:52:27 rhel7 journal: Journal started
Aug 13 11:52:27 rhel7 systemd: systemd 208 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ)

OS 起動時だけとはいえ、ログのタイムスタンプがずれることが許容できない場合はあるだろう。そのような場合、RTC は UTC にしておく必要がある。

実際 RHEL7 を触っていると、今回のように RTC が UTC であることを前提としている印象を受けることがある。今までは私も「そうは言ってもねえ、」とそれに抗っていたが、今回の件でスッパリと諦めた。正直、他にどういう副作用があるか知れない。なので現時点での結論は、

RHEL7 で余計な面倒に遭いたくないなら、RTC は UTC にしとけ。

後は、BIOS 時刻(9 時間遅れている)を見た人が、時刻を直してくれないことを祈るのみ。

2015-04-30

Animes in the 1st quarter of 2015

アニメは IT エンジニアの必須科目です。

いわく「バクマン。」のアニメ制作版。アニメ制作にこれだけの役職が本当に必要なのか疑問が残るが、勉強にはなった。で、やはりアニメは見る側に限る、との結論。

一見すると NHK がやってそうな作品。ギャグも多くヒロインも魅力的だが、何かもう一押し物足りない気がする。ともあれ、次回にも期待。

メカ良し、キャラもなかなか、声優も有名どころを揃えている。それでもつまらないのが昨今のサンライズクオリティ。ところでエンド後ってタスクしか種馬いなくね?

前作より視聴。相変わらず、気持ち偏重の展開。安心しては見られるが、楽しめば結果がついてくる、というのは本格的なスポーツ作品としては安易に思える。

人気漫画とのことで興味があったが、主人公が分かり易くて先が読める。むしろ野球に対する姿勢では古谷の方が好ましい。あと、続けて次期をやる意味が分からない。

話に深みは無さそうだと見ていたら、「俺は~強い」の種明かしには感心した。あと長引かせずに 2 クールで一旦終わらせたのも賢明だと思う。某海賊も見習えと言いたい。

原作は既読。早過ぎるアニメ化だと思ったら、原作も一緒に終わって納得。丁寧な作りで音にも拘っているようだが、やはり原作を読みたい。音への拘りは素人(私)には分からないし。

三期目らしいので、どんな物かと視聴。結果、「獣っ娘」需要と判断。話は仲良しごっこの温い内容で、良く言えば安心して見られる。しかしもう次回は見ないと思う。

原作を知らないのでキャラが多過ぎる。各キャラも全然掘り下げられていないし、これを 1 クールでやるのは無理だったと思う。あとプロデューサーがキモい。

暫く見て ED 絵のセンスがいいなと思ってから、実は作品を通してセンスが良いのではと思えてきた。惜しむらくは地味なこと。で最後、結局ちーちゃんは帰ってきたの? こなかったの? そこが気になる。

名前からして嫌な予感しかしないが、「ガッチャマンクラウズ」の例もあるのでスルーもできない。結果は玉砕。ドクロベエの中の人が現役だったのがうれしかったくらい。

エロが売りだろうにちっともエロくなく、話も平凡。そもそもこの手のエロって本当に需要があるのか。パンチラとかの方が余程理解できる。

前期より視聴。相変わらずダラーズ創始者がヘタレで、彼にフォーカスが当たると話が一気につまらなくなる。今回の終わり方を見るに、次回は更につまらない予感しかない。

あれで生きてるってないわー、と思ったのも束の間、元々インチキっぽかった主人公に更にチート能力を持たせるという展開に草。前期からの硬派な雰囲気が一気に台無しになった。

話は定番なので特に面白味はない。個人的に OP の動きのある線画が気に入ったが、それが作中には見られなかったのが残念。

調べなくても分かる、「輪るピングドラム」の人だ。輪る~では初話がピークだったが、本作では逆に話が進むにつれて面白くなってくる。ともあれ、ネタとして押さえておくべき作品。

前作から続いての視聴だが、未だに何が良いのか分からない。ヒロインの中の人が「三森すずこ」だったのを再発見したくらい。いっそ OP/ED も彼女に歌って欲しかった。

ファン向けであることを差し引いても、提督未経験の私から見て、絵も綺麗で良く纏まっているように思う。分からないネタも多いが、いろいろと勉強になるので次回も歓迎。

初見の印象は「あざとい」。しかし直ぐに本作の魅力は各ヒロインの個性だと分かる。強いて言うなら、他ヒロインに比べて四人目の個性が弱い感は否定できない。

須世璃にちょっとだけ萌えた以外は、特に取り立てるものがない。キャッチコピーを見ても作中に思い当たる節がないし、アニメ化か原作、どちらかに問題があるのかも。

2015-03-31

Bash: Number of CPU cores

インフラを自動化していると、CPU コア数に応じてパラメーターを変えたい、ということがある。Python だと /proc/cpuinfo からそれらを計算するライブラリーを自作していたりするのだが、書き捨てスクリプト、特に Bash で同じことをやりたい。

もちろん Bash でも頑張れば可能だが、書き捨てスクリプトでは「空で書ける」ことも重要。欲を言えば、Linux 間での可搬性があると尚良い。

以前にも調べたことはあって、その時は簡単にコア数を求める良い方法が見つからなかった。最近になってようやく満足のいく方法を見つけた。

これを参考にして、

cpuinfo.sh:

#!/bin/bash

ncpu_sockets() {
    cat /proc/cpuinfo \
	| grep -P '^physical id\s*:' \
	| sort -u \
	| wc -l
}

ncpu_cores() {
    cat /proc/cpuinfo \
	| grep -P '^(physical|core) id\s*:' \
	| paste - - \
	| sort -u \
	| wc -l
}

ncpu_processors() {
    cat /proc/cpuinfo \
	| grep -P '^processor\s*:' \
	| wc -l
}

echo sockets = $(ncpu_sockets)
echo cores = $(ncpu_cores)
echo processors = $(ncpu_processors)
# grep '^model name' /proc/cpuinfo | head -1
model name      : Intel(R) Xeon(R) CPU           E5640  @ 2.67GHz

# bash cpuinfo.sh
sockets = 2
cores = 8
processors = 16

やっていることのロジックさえ理解すれば、これくらいなら空で書くのも難しくない。paste コマンドは初見だったが、手持ちの RedHat 系 OS を見る限り何処にでも入っている基本コマンドのようだし、可搬性も問題ないだろう。

2015-02-18

Python: Unbuffered read and write

今回の環境。少し古いのは、そんな環境でも動かす必要があるから。

# cat /etc/redhat-release
CentOS release 5.5 (Final)

# rpm -q python
python-2.4.3-27.el5

長年システムの仕事をしていると、例えば「出力にタイムスタンプを付けたい」とかいうことが一度くらいはあるはず。普段そんな時は Perl でサクッと作るのだが、今回は訳あって Python を使う必要があった。

この手のスクリプトで考えるべきことの一つは、バッファリング制御。Python にもこの手のパターンというのがあって、少しググれば stackoverflow とかに山ほどスレッドが見つかる。

timestamp.py:

#!/usr/bin/python

import fileinput
import os
import signal
import sys
import time

sys.stdin = os.fdopen(sys.stdin.fileno(), 'rb', 0)
sys.stdout = os.fdopen(sys.stdout.fileno(), 'wb', 0)
signal.signal(signal.SIGPIPE, signal.SIG_DFL)

def main():
    for line in fileinput.input(sys.argv[1:]):
        sys.stdout.write(time.strftime('%F %T ') + line)
    return 0

if __name__ == '__main__':
    sys.exit(main())

上記で、fdopen の「おまじない」部分がそれに当たる。これで標準入出力のバッファリングを無効にしている。その下の signal 云々は、忌まわしき broken pipe を封じる呪文。これも Python 暗黒面の一つ。

と作ったスクリプトだが、

# ping -c 5 127.0.0.1 | python timestamp.py -
2015-02-18 18:41:42 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
2015-02-18 18:41:42 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.016 ms
2015-02-18 18:41:42 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.014 ms
2015-02-18 18:41:42 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.009 ms
2015-02-18 18:41:42 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.009 ms
2015-02-18 18:41:42 64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.016 ms
2015-02-18 18:41:42 
2015-02-18 18:41:42 --- 127.0.0.1 ping statistics ---
2015-02-18 18:41:42 5 packets transmitted, 5 received, 0% packet loss, time 3999ms
2015-02-03 18:41:42 rtt min/avg/max/mdev = 0.009/0.012/0.016/0.005 ms

全然効いてなーい。めっちゃバッファリングしてる。

前述のおまじない以外にも、Python の起動オプション -u でバッファリングを無効にできるが、それでやっても結果は変わらず。訳が分からないので help & man を良く読んでみる。

# python -h

<...snip...>

-u     : unbuffered binary stdout and stderr (also PYTHONUNBUFFERED=x)
         see man page for details on internal buffering relating to '-u'

# man python

<...snip...>

       -u     Force stdin, stdout and stderr to  be  totally  unbuffered.   On
              systems  where  it matters, also put stdin, stdout and stderr in
              binary mode.  Note that there is internal  buffering  in  xread-
              lines(),  readlines()  and  file-object  iterators ("for line in
              sys.stdin") which is not influenced by  this  option.   To  work
              around  this, you will want to use "sys.stdin.readline()" inside
              a "while 1:" loop.

man の方に衝撃的なことが書いてある。「このオプションは xreadlines, readlines, イテレーターには効かないので、while + readline を使えよ」って、それってあんまりじゃね? readlines の方はともかく、イテレーターには裏切られた気持ちで一杯だ。

と文句を言っても仕方がないので、while + readline で書き直してみる。

def main():
    readline = fileinput.input(sys.argv[1:]).readline
    while True:
        line = readline()
        if not line:
            break
        sys.stdout.write(time.strftime('%F %T ') + line)
    return 0

しかし結果は全く変わらず。もしかして、と思い fileinput の実装を見てみると、

案の定、FileInput.readline 中で readlines を使っており、ここでバッファリングされるらしい。Python3 でも改善は見られず。なんだよ fileinput、使えねー。今までこの手のファイル入力にはずっと fileinput を使ってきたが、今後は考え直した方が良さそうだ。

そんなこんなで、最終的には次のようになった。

timestamp.py:

#!/usr/bin/python

import os
import signal
import sys
import time

sys.stdin = os.fdopen(sys.stdin.fileno(), 'rb', 0)
sys.stdout = os.fdopen(sys.stdout.fileno(), 'wb', 0)
signal.signal(signal.SIGPIPE, signal.SIG_DFL)

def main():
    for arg in sys.argv[1:]:
        fh = arg == '-' and sys.stdin or open(arg, 'rb', 0)
        try:
            for line in iter(fh.readline, ''):
                sys.stdout.write(time.strftime('%F %T ') + line)
        finally:
            if fh is not sys.stdin:
                fh.close()
    return 0

if __name__ == '__main__':
    sys.exit(main())
# ping -c 5 127.0.0.1 | python timestamp.py -
2015-02-18 18:46:36 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
2015-02-18 18:46:36 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.019 ms
2015-02-18 18:46:37 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.012 ms
2015-02-18 18:46:38 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.011 ms
2015-02-18 18:46:39 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.009 ms
2015-02-18 18:46:40 64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.009 ms
2015-02-18 18:46:40 
2015-02-18 18:46:40 --- 127.0.0.1 ping statistics ---
2015-02-18 18:46:40 5 packets transmitted, 5 received, 0% packet loss, time 3999ms
2015-02-03 18:46:40 rtt min/avg/max/mdev = 0.009/0.012/0.019/0.003 ms

実際には、上記だと、fdopen のおまじないが無くてもそれらしく動く。少なくともテストした限りではそうだった。結局のところ、

  • イテレーターが入力をバッファリングする
  • fileinput は readline でさえも、入力をバッファリングする

というのが事の元凶だったらしい。特に fileinput、お前はこの手のリアルタイム入力には二度と使わねえ。

まさかこんな単純なスクリプトにここまでハマるとは思わなかった。これでまた一つ Python が嫌いになった。使えば使うほど嫌いになっていくのが Python、使うほど手に馴染んでいくのが Perl。(但し OOP は除く)


2016-07-18 追記

fileinput の方は、最近になって修正されたっぽい。たぶん 2.7.12 と 3.5.2 から。動作は未確認。

しかし、元々 fileinput が readlines を使うようになったのは高速化のためだろうから、全く readlines を使わないようにした上記の修正には疑問が残る。組み込みファイルオブジェクトのように、readline だけバッファリングしないように UI を合わせる手は無かったのだろうか。

2015-01-31

Animes in the 4th quarter of 2014

アニメは IT エンジニアの必須科目です。

どう見てもタツミが主人公な件。途中から敵側キャストも拡充されるが、余り盛り上がらずに終息。まあ「どちらかが死ぬ」という設定上、最後が尻すぼみになるのは必然とも言える。

前作は未見。頑張り屋さんのイイ話系かと思ったら、ヒロインが結構ヘタレなのでそうでもない。萌えられるキャラも居なかったが、短尺(15 分)なので見るのは楽だった。

前作からの視聴。相変わらず脚本は聞いている側が恥ずかしくなるレベル。最早ネタのために見てるといっても過言ではない。もちろん次回も見るつもり。

初見で期待してなかったが、やたらと女子キャラのリアクションが可愛い。特にひおたんが秀逸で、監督が苛めたくなる気持ちも分かる。これは是非続きをやってもらいたい。

これこそ私が見たかった正当な Fate な感。しかし主人公が理想を口にするだけのヘタレなことが分かって幻滅。Fate ルートは未視聴だが、見なくても大体予想がついた。多分シリーズでは Fate/Zero が一番ではあるまいか。

ゲーム原作なので全く期待してなかったが、見事に裏切ってくれた。話はもう一押し欲しいが、これだけ丁寧に作り込んでいることに好感が持てる。他のゲーム原作アニメも少しは見習え。

チョロいヒロインにツンデレ彼氏、少女マンガの典型パターン。男が見ても面白味はないが、イケメンなんかに負けないっ→イケメンには勝てなかったよ、に置き換えれば少しは楽しめるか。

何でも脚本が有名人とのことで注意深く視聴していたが、特に何も感じなかった。と言いながら最終話はちょっと涙出してたけど、年寄りは涙腺が弱いので当てにならない。

タイムループ物にしては最後を綺麗に纏めてきたような気もする。が、実は余り良く理解できていない。かといって復習する気もなし。元ネタがエロゲだとは後日知った。

これが噂の進撃(集英社版)ですか。最初は面白く見ていたのだが、火星に降りたくらいから飽きてきた。ゴキがバカっぽいのが原因だと思う。昆虫の勉強には良いのではないかと。

話の内容に言うことはないが、前期に続いて後期もいきなり終わり過ぎ。せめて区切りのある終わり方にしてくれ。劇場版が控えていることは理由にならない。

往年の SEGA 作品が見れて楽しいのだが、ゲーム紹介に留まっていて、当時を生きた老人としては全然足りない。ハードとしてのサターンは好きではなかったが、本サターン(SD キャラ)は可愛くて仕方がない。

主人公強い・ハーレム・ラッキースケベという定番パターンの詰め合わせ。取りあえず、「アーカイブに接続、テーマを実行する」とさえ言っておけば大体合ってる。

清々しい程の中二病に格好良ささえ感じる。各キャラも個性があり絵も綺麗、話も基本コミカルで安心して見れる。この雰囲気を崩さずに、是非第二期をやって欲しい。

魔法少女が不幸を背負うようになったのは、まどマギの罪だと思う。どう終わらせるのか注目していたら、理不尽なハッピーエンドになった。この評価は分かれそうだが、不幸になるよりはマシ。

最初は絵が綺麗なだけと思っていたが、話が進むにつれて各キャラがジワジワ来る。これが原作によるものか、京アニによるものかは不明。フルメタの作者だとは後日知った。

前作からの視聴。パッとしないキャラ揃えからヴィヴィがブレイクするかと思いきや、不発。話も安定の予定調和で終了。萌えられるキャラが居ればまた評価は違ったかも。

前作からの視聴。カムイの言うことがさっぱり分からない上、オカルト現象の種明かしも無し。同じ制作陣が作ったとは思えない。前作が良かったので期待が大きかった分、失望も大きい。