■rsyslogの仕掛けを使って、普段使いのデスクトップやノートPCの稼働状態をLinuxサーバーに集めるということをやっているのだけど、Fedoraは20からrsyslogを排してjournalに一本化するのだという。rsyslogよりもjournalの方が使いやすいということなのだろうけど、こちらが使っているrsyslogの仕掛けが使えなくなるのはちょっと困る。出先で状態監視に使っているだけなので、立ち行かなくなるわけではないのだけど、出先でちょくちょく監視して状態がおかしいことに気付いて対策を考えてから帰るのと、帰ってからいきなり不調に気が付くのとでは精神衛生的に大きく違う。
journald(systemd-journal)でもリモートから受け付けるAPIは持っている(systemd-journal-upload)ようなのだけど、今のFedora19では実装されておらず、Fedora21の開発バージョンにはあるらしい、ということはなんとなく調べた。その状態でFedora20に上げてしまうとrsyslogはなくなるし、jounarldはリモートから受け付けられなくなるしで困ってしまう。とりあえずなんでもいいのでjournalにメッセージを書き込む仕掛けは何かと調べてみるとsd_journal(3)が見つかりました。これまたmanでドキュメントをさらってみても今ひとつ使い方が解らないのですが、コーディング例を探し出してなんとなく解ってきました。
ただ、やはりリモートから書き込むインターフェースではない（サーバー上のライブラリなのだから当然ですが）ので、そこはインターフェースを作ってやる必要があります。
仕掛けは単純で、TCPのソケット通信経由で受信したメッセージをsd_journalへ転送してやるだけです。journalが持つデータ構造(systemd.journal-fields)にはリモートを識別するためのタグがそもそもないので、メッセージ発信者の識別情報などをすべて可読文字列に押し込んでMESSAGEとしてjournalに流すしかなさそうです。メッセージ受信プロセスはデーモン化して常駐させ、SIGINTなどを受信するとソケットをクローズして停止するようにすれば使い勝手も多少よくなるでしょう。
FedoraをUpgradeすると必要なくなるというのが微妙なところですが、仕掛けが切り替わるときのつなぎということで、そこは妥協することに。
プログラムの構造は起動してから自身をデーモン化する(fork & getsid)部分と、受信状態になって待機する(listen & accept)部分、受信した後に子プロセス化して、子プロセス側で受信処理とjounarlへの書き込み処理をする部分の３つにだいたいわかれる。ものすごく久しぶりにCでコーディングしたのですが、PHPで長いことコーディングをしていからか、ひどく立ち往生することもなく書き下すことができました。家電制御デバイスのサーバープログラムを書くときに似たような構造のプログラムをPHPで書いていたことが良かったようです。ただ、あんまりきれいなコーディングではなくて、後でメンテナンスが大変になりそうです。
