bug#40220: date command set linux epoch time failed
Hi all: I use command date -s "1970-01-20 00:00:00" to set date, but it failed. there is error message "date: can't set date: Invalid argument". It's UTC time and no timezone. I test with stime or settimeofday to set seconds 0, they are all have the problem. 1. I use buildroot-2013.05, the busybox is in 1.21.1, the linux kernel is in version 4.4.39. # date -s "1970-01-20 00:00:00" Tue Jan 20 00:00:00 UTC 1970 # date -R Tue, 20 Jan 1970 00:00:03 + # date -s "1970-01-01 00:00:00" date: can't set date: Invalid argument Thu Jan 1 00:00:00 UTC 1970 2. I test in ubuntu version 14.04.1. shy@ubuntu:/etc$ sudo date -s "2020-03-01 00:00:00" Sun Mar 1 00:00:00 UTC 2020 shy@ubuntu:/etc$ date -R Sun, 01 Mar 2020 00:00:03 + shy@ubuntu:/etc$ sudo date -s "1970-01-01 00:00:00" date: cannot set date: Invalid argument Thu Jan 1 00:00:00 UTC 1970 shy@ubuntu:/etc$ uname -a Linux ubuntu 4.4.0-142-generic #168~14.04.1-Ubuntu SMP Sat Jan 19 11:26:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux 3.When set date command, the busybox uses function "stime" to set time, I use stime to set time around linux epoch time, but the stime seems not work well. int ret = 0; time_t time = 20; ret = stime(&time); printf("ret %d %d\r\n",ret, errno); perror("stime:"); and the results are as follows: ret -1 22 stime:: Invalid argument Best regards!
bug#40220: date command set linux epoch time failed
tag 40220 + notabug close 40220 thanks shy wrote: > I use command date -s "1970-01-20 00:00:00" to set date, but it > failed. there is error message "date: can't set date: Invalid > argument". > It's UTC time and no timezone. This is most likely a limitation of your kernel. I can recreate this problem on a Linux 4.9 system for example. TZ=UTC strace -o /tmp/out -v date -s "1970-01-01 00:00:00" ... clock_settime(CLOCK_REALTIME, {tv_sec=0, tv_nsec=0}) = -1 EINVAL (Invalid argument) settimeofday({tv_sec=0, tv_usec=0}, NULL) = -1 EINVAL (Invalid argument) ... And the documented possible returns of EINVAL for clock_settime(). EINVAL The clk_id specified is not supported on this system. EINVAL (clock_settime()): tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999]. EINVAL (since Linux 4.3) A call to clock_settime() with a clk_id of CLOCK_REALTIME attempted to set the time to a value less than the current value of the CLOCK_MONOTONIC clock. And for settimeofday(). EINVAL (settimeofday()): timezone is invalid. EINVAL (settimeofday()): tv.tv_sec is negative or tv.tv_usec is outside the range [0..999,999]. EINVAL (since Linux 4.3) (settimeofday()): An attempt was made to set the time to a value less than the current value of the CLOCK_MONOTONIC clock (see clock_gettime(2)). EPERM The calling process has insufficient privilege to call settimeofday(); under Linux the CAP_SYS_TIME capability is required. But this is not a bug in GNU date. This is likely the effect of CLOCK_MONOTONIC in the Linux kernel. 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. I am not familiar with CLOCK_MONOTONIC but reading the documentation points me to it as being the most likely reason this is not allowing that time to be set. 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. > I test with stime or settimeofday to set seconds 0, they are all have the > problem. > 1. I use buildroot-2013.05, the busybox is in 1.21.1, the linux kernel is in > version 4.4.39. That multiple frontends, GNU date and busybox date, all have the same problem speaks that the problem is not with the frontend but with the kernel handling the system call. > 3.When set date command, the busybox uses function "stime" to set > time, I use stime to set time around linux epoch time, >but the stime seems not work well. >int ret = 0; >time_t time = 20; >ret = stime(&time); >printf("ret %d %d\r\n",ret, errno); >perror("stime:"); > and the results are as follows: > ret -1 22 > stime:: Invalid argument And also confirmed by your independent test the the problem is not a bug in GNU date. Therefore I mark this GNU date bug ticket as closed for our own accounting. But please continue to discuss the issue here. Bob
bug#40220: date command set linux epoch time failed
On 3/27/20 11:52 PM, 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?
bug#40220: date command set linux epoch time failed
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
bug#40220: date command set linux epoch time failed
On 3/28/20 9:12 AM, Bob Proulx wrote: By reading the documentation for CLOCK_MONOTONIC in clock_gettime(2): GNU 'date' doesn't use CLOCK_MONOTONIC, so why is CLOCK_MONOTONIC relevant to this bug report? Is this some busybox thing? If so, user 'shy' needs to report it to the busybox people, not to bug-coreutils.
bug#40220: date command set linux epoch time failed
Paul Eggert wrote: > Bob Proulx wrote: > > By reading the documentation for CLOCK_MONOTONIC in clock_gettime(2): > > GNU 'date' doesn't use CLOCK_MONOTONIC, so why is CLOCK_MONOTONIC relevant > to this bug report? GNU date uses clock_settime() and settimeofday() on my Debian system. Let me repeat the strace snippet from my previous message which shows this. TZ=UTC strace -o /tmp/out -v date -s "1970-01-01 00:00:00" ... clock_settime(CLOCK_REALTIME, {tv_sec=0, tv_nsec=0}) = -1 EINVAL (Invalid argument) settimeofday({tv_sec=0, tv_usec=0}, NULL) = -1 EINVAL (Invalid argument) ... Both calls from GNU date are returning EINVAL. Those are Linux kernel system calls. Those Linux kernel system calls are using CLOCK_MONOTONIC. Therefore GNU date, on Linux systems, is by association with the Linux kernel, using CLOCK_MONOTONIC. And the Linux kernel is returning EINVAL. And according to the documentation for both clock_settime() and settimeofday() the most likely reason for the EINVAL is the application of CLOCK_MONOTONIC preventing it, because that documentation says that one cannot set the date earlier than the system uptime. Why this is desirable I have no idea as it does not seem desirable to me. But I am just the messenger, having read that in the documentation looking for the reason for the EINVAL return. > Is this some busybox thing? If so, user 'shy' needs to report it to the > busybox people, not to bug-coreutils. No. It is only a busybox thing as much as it is a GNU date thing in that both are making system calls to the Linux kernel and both are failing with EINVAL. The reference to busybox confused me at first too. But in the original report it was simply another case of the same thing. Which is actually a strong indication that it is not a bug in either of the frontend implementations but something common to both. In this case the kernel is the common part. This does not appear to be a bug in the sense that it is explicit behavior. It is working as the Linux kernel has coded it to behave. According to the documentation. If one were to take this anywhere it would be to the Linux kernel mailing list to discover why they implemented this inconvenient behavior. Meanwhile... Since I am writing this in this thread... I might mention to the original poster that if they are testing using old clock times they might be able to get a good result by using libfaketime https://github.com/wolfcw/libfaketime which is a user land strategy for implementing different fake clock times for programs. Very useful in testing. And then there would be no need to set the system time at all. $ faketime '1970-01-01 00:00:00 UTC' date -uR Thu, 01 Jan 1970 00:00:00 + Bob
bug#40220: date command set linux epoch time failed
On 3/29/20 9:32 PM, Bob Proulx wrote: Both calls from GNU date are returning EINVAL. Those are Linux kernel system calls. Those Linux kernel system calls are using CLOCK_MONOTONIC. OK, I think I understand now. For some reason Linux prohibits you from setting CLOCK_REALTIME to a value less than what CLOCK_MONOTONIC would report. I don't know why Linux has this restriction - it violates POSIX as near as I can tell - but at any rate as you say it's a problem with the Linux kernel, not with GNU 'date'.