Paul Eggert wrote:
> Bob Proulx wrote:
> > I tested this in a victim system and if I was very quick I was able to
> > log in and set the time to :10 seconds but no earlier.
>
> Sounds like some sort of atomic-time thing, since UTC and TAI differed by 10
> seconds when they started up in 1972. Perhaps the clock in question uses TAI
> internally?
By reading the documentation for CLOCK_MONOTONIC in clock_gettime(2):
CLOCK_MONOTONIC
Clock that cannot be set and represents monotonic time since--as
described by POSIX--"some unspecified point in the past". On
Linux, that point corresponds to the number of seconds that the
system has been running since it was booted.
The CLOCK_MONOTONIC clock is not affected by discontinuous jumps
in the system time (e.g., if the system administrator manually
changes the clock), but is affected by the incremental
adjustments performed by adjtime(3) and NTP. This clock does
not count time that the system is suspended.
It's the, "On Linux, that point corresponds to the number of seconds
that the system has been running since it was booted." part that seems
to apply here just by the reading of it. To test this I can reboot a
VM, which boots quickly, and then as soon as I think it is available
by watching the console I can ssh into it as root from another
terminal. And then in that other terminal logged in as root I try to
execute "date -s '1970-01-01 00:00:00 UTC'" as soon as possible. I am
never able to do so due to EINVAL.
But if I reboot and repeat the experiment trying to set a few seconds
in time later then if I am quick I can sometimes catch "date -s
'1970-01-01 00:00:10 UTC'" and have it work. Trying again now I was
able to be quick and get logged in and set in :07 UTC. But then if I
wait and let seconds tick by and try setting to :10 UTC seconds again
it will fail. This matches the model described by the documentation
that CLOCK_MONOTONIC is the system uptime and the kernel is not
allowing the clock set to be before the system uptime.
If I wait longer and try setting the date to various times then
experimentally the behavior matches that I cannot set the system time
earlier than the the system uptime.
Personally I can't see an advantage for this behavior. Because if
someone is doing an experiment and wants to reset the clock to time
zero then I don't see an advantage of blocking that from happening.
However doing so might avoid some accidental settings of the system
clock to an unintended zero time. Just like rm --preserve-root. But
how often does that actually happen? And then I would want to see a
way to do it anyway for the experiment possibilities. Here reading
the documentation it seems to be a new hard limitation coded into the
Linux kernel that is blocking this.
Bob
