Public bug reported:
I have a raspberry pi with fake-hwclock installed and it seems the
documented behaviour doesn't work E.g. from /lib/systemd/system/systemd-
timesyncd.service, specifically: "ensure [clock] monotonically advances
even if the system lacks a battery-buffered RTC chip" - this doesn't
actually happen.
I have tried editing /lib/systemd/system/fake-hwclock.service to have:
[Unit]
Description=Restore / save the current clock
Documentation=man:fake-hwclock(8)
DefaultDependencies=no
Before=systemd-update-utmp.service sysinit.target
Conflicts=shutdown.target
I also tried to edit /lib/systemd/system/systemd-update-utmp.service to have:
[Unit]
Description=Update UTMP about System Boot/Shutdown
Documentation=man:systemd-update-utmp.service(8) man:utmp(5)
DefaultDependencies=no
RequiresMountsFor=/var/log/wtmp
Conflicts=shutdown.target
# After=systemd-remount-fs.service systemd-tmpfiles-setup.service
auditd.service fake-hwclock.service
After=systemd-timesyncd.service fake-hwclock.service time-sync.target
Before=sysinit.target shutdown.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStartPre=/sbin/fake-hwclock load
ExecStart=/lib/systemd/systemd-update-utmp reboot
ExecStop=/lib/systemd/systemd-update-utmp shutdown
However on reboot, the wtmp file is still being updated before systemd-
update-utmp.service and fake-hwclock:
$ last reboot | head -n 3
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 - 22:04
(17316+21:04)
reboot system boot 4.4.0-1055-raspi Thu Jan 1 01:00 - 22:04
(17316+21:04)
Looking at the journalctl I can see the time is already set and
/var/log/wtmp is already updated to 1970 before any of the above can
run:
$ sudo journalctl -u systemd-update-utmp
-- Logs begin at Wed 2017-06-07 17:18:08 IST, end at Wed 2017-06-07
17:19:05 IST. --
Jun 07 17:18:14 TimeBox systemd[1]: Starting Update UTMP about System
Boot/Shutdown...
Jun 07 17:18:14 TimeBox fake-hwclock[823]: Current system time: 2017-06-07
16:18:14
Jun 07 17:18:14 TimeBox fake-hwclock[823]: fake-hwclock saved clock
information is in the past: 2017-06-07 16:18:08
Jun 07 17:18:14 TimeBox fake-hwclock[823]: To set system time to this saved
clock anyway, use "force"
Jun 07 17:18:14 TimeBox systemd[1]: Started Update UTMP about System
Boot/Shutdown.
So the "Update UTMP about System Boot/Shutdown." doesn't work, the time
is already set to 1 Jan 1970 by something else.
How do I run a service/command before /var/log/wtmp is touched and set
to 1 Jan 1970? - It seems the documented behaviour/methods do not work.
I'm using Ubuntu 16.04 with systemd 229-4ubuntu17
** Affects: systemd (Ubuntu)
Importance: Undecided
Status: New
** Tags: fakehw-clock raspberrypi rtc systemd
** Description changed:
I have a raspberry pi with fake-hwclock installed and it seems the
documented behaviour doesn't work E.g. from /lib/systemd/system/systemd-
timesyncd.service, specifically: "ensure [clock] monotonically advances
even if the system lacks a battery-buffered RTC chip" - this doesn't
actually happen.
I have tried editing /lib/systemd/system/fake-hwclock.service to have:
- [Unit]
- Description=Restore / save the current clock
- Documentation=man:fake-hwclock(8)
- DefaultDependencies=no
- Before=systemd-update-utmp.service sysinit.target
- Conflicts=shutdown.target
+ [Unit]
+ Description=Restore / save the current clock
+ Documentation=man:fake-hwclock(8)
+ DefaultDependencies=no
+ Before=systemd-update-utmp.service sysinit.target
+ Conflicts=shutdown.target
+
+
I also tried to edit /lib/systemd/system/systemd-update-utmp.service to have:
- [Unit]
- Description=Update UTMP about System Boot/Shutdown
- Documentation=man:systemd-update-utmp.service(8) man:utmp(5)
- DefaultDependencies=no
- RequiresMountsFor=/var/log/wtmp
- Conflicts=shutdown.target
- # After=systemd-remount-fs.service systemd-tmpfiles-setup.service
auditd.service fake-hwclock.service
- After=systemd-timesyncd.service fake-hwclock.service time-sync.target
- Before=sysinit.target shutdown.target
+ [Unit]
+ Description=Update UTMP about System Boot/Shutdown
+ Documentation=man:systemd-update-utmp.service(8) man:utmp(5)
+ DefaultDependencies=no
+ RequiresMountsFor=/var/log/wtmp
+ Conflicts=shutdown.target
+ # After=systemd-remount-fs.service systemd-tmpfiles-setup.service
auditd.service fake-hwclock.service
+ After=systemd-timesyncd.service fake-hwclock.service time-sync.target
+ Before=sysinit.target shutdown.target
- [Service]
- Type=oneshot
- RemainAfterExit=yes
- ExecStartPre=/sbin/fake-hwclock load
- ExecStart=/lib/systemd/systemd-update-utmp reboot
- ExecStop=/lib/systemd/systemd-update-utmp shutdown
- However on reboot, the wtmp file is still being updated before
systemd-update-utmp.service and fake-hwclock:
+ [Service]
+ Type=oneshot
+ RemainAfterExit=yes
+ ExecStartPre=/sbin/fake-hwclock load
+ ExecStart=/lib/systemd/systemd-update-utmp reboot
+ ExecStop=/lib/systemd/systemd-update-utmp shutdown
- $ last reboot | head -n 3
- 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 - 22:04 (17316+21:04)
- reboot system boot 4.4.0-1055-raspi Thu Jan 1 01:00 - 22:04 (17316+21:04)
- Looking at the journalctl I can see the time is already set and /var/log/wtmp
is already updated to 1970 before any of the above can run:
+ However on reboot, the wtmp file is still being updated before systemd-
+ update-utmp.service and fake-hwclock:
- $ sudo journalctl -u systemd-update-utmp
- -- Logs begin at Wed 2017-06-07 17:18:08 IST, end at Wed 2017-06-07 17:19:05
IST. --
- Jun 07 17:18:14 TimeBox systemd[1]: Starting Update UTMP about System
Boot/Shutdown...
- Jun 07 17:18:14 TimeBox fake-hwclock[823]: Current system time: 2017-06-07
16:18:14
- Jun 07 17:18:14 TimeBox fake-hwclock[823]: fake-hwclock saved clock
information is in the past: 2017-06-07 16:18:08
- Jun 07 17:18:14 TimeBox fake-hwclock[823]: To set system time to this saved
clock anyway, use "force"
- Jun 07 17:18:14 TimeBox systemd[1]: Started Update UTMP about System
Boot/Shutdown.
- So the "Update UTMP about System Boot/Shutdown." doesn't work, the time is
already set to 1 Jan 1970 by something else.
+ $ last reboot | head -n 3
+ 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 - 22:04
(17316+21:04)
+ reboot system boot 4.4.0-1055-raspi Thu Jan 1 01:00 - 22:04
(17316+21:04)
+
+ Looking at the journalctl I can see the time is already set and
+ /var/log/wtmp is already updated to 1970 before any of the above can
+ run:
+
+ $ sudo journalctl -u systemd-update-utmp
+ -- Logs begin at Wed 2017-06-07 17:18:08 IST, end at Wed 2017-06-07
17:19:05 IST. --
+ Jun 07 17:18:14 TimeBox systemd[1]: Starting Update UTMP about System
Boot/Shutdown...
+ Jun 07 17:18:14 TimeBox fake-hwclock[823]: Current system time:
2017-06-07 16:18:14
+ Jun 07 17:18:14 TimeBox fake-hwclock[823]: fake-hwclock saved clock
information is in the past: 2017-06-07 16:18:08
+ Jun 07 17:18:14 TimeBox fake-hwclock[823]: To set system time to this
saved clock anyway, use "force"
+ Jun 07 17:18:14 TimeBox systemd[1]: Started Update UTMP about System
Boot/Shutdown.
+
+ So the "Update UTMP about System Boot/Shutdown." doesn't work, the time
+ is already set to 1 Jan 1970 by something else.
How do I run a service/command before /var/log/wtmp is touched and set
to 1 Jan 1970? - It seems the documented behaviour/methods do not work.
I'm using Ubuntu 16.04 with systemd 229-4ubuntu17
** Tags added: raspberrypi
** Tags added: fakehw-clock rtc systemd
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1696500
Title:
/var/log/wtmp is updated to 1970-01-01 before systemd-update-
utmp.service (or fake-hwclock)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1696500/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
