Timer using OnCalendar= has next elapse stuck on MANAGER_TIMESTAMP_USERSPACE #16347

master (a68da22)

We have some newly provisioned hosts that may boot with the wrong time (in this case, very far into the future). During boot the clock syncs. By the end of system start up, the time will be correct.

However, timers configured with OnCalendar= will have a next elapse/trigger time set to very far into the future (in the range of the time at boot). It seems to be caused by this code: https://github.com/systemd/systemd/blob/master/src/core/timer.c#L390-L395. Even though v->next_elapse is correct relative to what the time is now, UNIT(t)->manager->timestamps[MANAGER_TIMESTAMP_USERSPACE].realtime is in the future so next elapse gets stuck to this value.

Besides the comment in the code being incorrect (it's intended for persistent timers but affects non-persistent ones), I'm not sure checking against a stored realtime is a good idea when the clock could change at any time. But then I'm not sure what the right logic would be to fix the original problem and my current problem.

Steps to reproduce the problem
Not an exact repro, but close enough to see the effect:

# set clock forward on the host
sudo date -s "Jul 2 22:45:10 PDT 2023"

# boot a container for the test
systemd-nspawn -bi image.raw

# set clock back on the host
sudo date -s "Jul 2 22:45:10 PDT 2020"

# create and observe the timer in the container
systemd-run --unit test --on-calendar '*:0/15:0' touch /tmp/testfile
systemctl show test.timer -p NextElapseUSecRealtime # shows a time around 2023
systemd-analyze dump | grep userspace # shows the exact same time as above