systemd-journaldが起動しない

/var/log/secureやら/var/log/messageやらが結構昔からログ吐かれていなかった。
systemd-journaldの様子を見てみると生きてるっぽいけど、謎の警告がでている。

systemctl status systemd-journald
* systemd-journald.service - Journal Service
   Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static; vendor preset: disabled)
   Active: active (running) since Wed 2016-09-14 16:21:34 JST; 1 years 7 months ago
     Docs: man:systemd-journald.service(8)
           man:journald.conf(5)
 Main PID: 335 (systemd-journal)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-journald.service
           `-335 /usr/lib/systemd/systemd-journald

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

警告メッセージでググると、/etc/machine-idを作り直して再起動とか、/var/log/journal/xxxx/*なファイルを消すとかjournalctl --verifyを確認してみるとかでてくるけど、どれもピンとこない。

dmesg | grep journal
[    2.079626] systemd-journald[89]: Received SIGTERM from PID 1 (systemd).
[    2.401504] systemd-journald[335]: Received request to flush runtime journal from PID 1
[25819418.741189] systemd-journald[335]: Failed to create new runtime journal: No space left on device

dmesgを確認すると、ディスク容量がないというそれっぽいログが出ていて、uptimeと突き合わせてもログが吐かれなくなったタイミングと一致している。 ディスクが一杯になったことはないはずなのだけれど、確認してみると/runにはディスク (/dev/vda3)とは別にtmpfsがマウントされていて、それが99%になっていた。
systemd-journald(8) によると、

By default, the journal stores log data in /run/log/journal/. Since /run/ is volatile, log data is lost at reboot. To make the data persistent, it is sufficient to create /var/log/journal/ where systemd-journald will then store the data:

ということで、mkdir /var/log/journalさえすれば/runの下は見なくなる。
実際、そうすることでリブートすることなくsystemd-journaldを再起動できた。

エラーメッセージが分かりにくいし、特定ディレクトリの有無だけで設定ファイルに関係なく挙動が変わるのも違和感がすごい。