☰

/var/log/wtmp が更新される前に fake-hwclock を実行するにはどうすればよいですか?

tag-icon • tag-icon systemd raspberry-pi wtmp
/var/log/wtmp が更新される前に fake-hwclock を実行するにはどうすればよいですか?

私はラズベリーパイを持っていますが、再起動するたびに最後に次の出力が表示されます:

root@RaspberryPi:~# last | grep boot
reboot   system boot  4.4.0-1055-raspi Thu Jan  1 01:00   still running
reboot   system boot  4.4.0-1055-raspi Thu Jan  1 01:00   still running
reboot   system boot  4.4.0-1055-raspi Thu Jan  1 01:00 - 23:01 (17305+22:01)
reboot   system boot  4.4.0-1055-raspi Thu Jan  1 01:00 - 23:01 (17305+22:01)
reboot   system boot  4.4.0-1055-raspi Thu Jan  1 01:00 - 23:01 (17305+22:01)

これは、fake-hwclock とハードウェア RTC の両方がインストールされているにもかかわらず発生します。

現在、fake-hwclock.service のサービスは、次のように sysinit.target の前に開始されます。

[Unit]
Before=sysinit.target

[Service]
ExecStart=/sbin/fake-hwclock load

[Install]
WantedBy=sysinit.target

/var/log/wtmp が更新される前に実行するにはどうすればよいですか?

答え1

これは systemd-update-utmp のバグだと思います。こちらのコメントをご覧ください:https://github.com/systemd/systemd/issues/6057#issuecomment-435247567

回避策としては、メインの systemd インスタンスに制御を渡す前に、initramfs で fake-hwclock を実行します。

答え2

wtmp の「再起動」ログイン レコードは、systemd-update-utmp systemd サービスによって処理されます。これは sysinit ターゲットの前に開始する必要があります。つまり、このサービスがまだ開始されていない場合は、開始が完了する前に開始されます。systemd-timesyncd が必ずしも systemd-update-utmp の前に開始されるわけではありません。

私は自分の Arch Linux サーバーでテストしましたが、systemd-timesyncd は常に systemd-update-utmp より先に正常に実行されます。一方、それらはほぼ常に互いに 1 つの pid 離れています。

しかし、NTP の後に明示的に実行されていないため、これは依然としてバグと見なされるべきだと思います。

systemd マニュアルより:

「後=は逆Before= の、つまり、After= は、リストされたユニットの起動が完了した後に、構成されたユニットが起動されることを保証します。

https://www.freedesktop.org/software/systemd/man/systemd.unit.html

あなたがすべきこと:

systemctl edit systemd-update-utmp

[Unit]
After=systemd-timesyncd.service
Wants=systemd-timesyncd.service

関連情報