☰

/var/log/wtmpを更新する前にfake-hwclockを実行する方法は？

tag-icon • tag-icon systemd raspberry-pi wtmp
/var/log/wtmpを更新する前にfake-hwclockを実行する方法は？

私はRaspberry Piを持っており、再起動するたびに最後に次の出力が表示されます。

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

回避策は、デフォルトのシステムインスタンスに制御を渡す前に、initramfsでfake-hwclockを実行することです。

答え2

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

私のアーチLinuxサーバーでテストしましたが、systemd-timesyncdはsystemd-update-utmpより前に常にうまく機能しました。一方、彼らはほぼ常にお互いにピッド離れています。

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

システムマニュアルから：

"=次に駅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

関連情報