GNU bug report logs - #40220
date command set linux epoch time failed

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40220 in the body.
You can then email your comments to 40220 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: shy  <mail_hysong <at> 163.com>
To: bug-coreutils <at> gnu.org
Subject: date command set linux epoch time failed
Date: Wed, 25 Mar 2020 09:40:13 +0800 (CST)

[Message part 1 (text/plain, inline)]

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 +0000
# 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 <at> ubuntu:/etc$ sudo date -s "2020-03-01 00:00:00"
Sun Mar  1 00:00:00 UTC 2020
shy <at> ubuntu:/etc$ date -R
Sun, 01 Mar 2020 00:00:03 +0000

shy <at> 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 <at> 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!








 

[Message part 2 (text/html, inline)]

Message #8 received at 40220 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: shy <mail_hysong <at> 163.com>
Cc: 40220 <at> debbugs.gnu.org
Subject: Re: bug#40220: date command set linux epoch time failed
Date: Sat, 28 Mar 2020 00:52:32 -0600

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

Message #15 received at 40220 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bob Proulx <bob <at> proulx.com>, shy <mail_hysong <at> 163.com>
Cc: 40220 <at> debbugs.gnu.org
Subject: Re: bug#40220: date command set linux epoch time failed
Date: Sat, 28 Mar 2020 01:00:49 -0700

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?

Message #18 received at 40220 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: 40220 <at> debbugs.gnu.org
Cc: shy <mail_hysong <at> 163.com>
Subject: Re: bug#40220: date command set linux epoch time failed
Date: Sat, 28 Mar 2020 10:12:16 -0600

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

Message #21 received at 40220 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bob Proulx <bob <at> proulx.com>, 40220 <at> debbugs.gnu.org
Cc: shy <mail_hysong <at> 163.com>
Subject: Re: bug#40220: date command set linux epoch time failed
Date: Sun, 29 Mar 2020 20:50:59 -0700

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.

Message #24 received at 40220 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: 40220 <at> debbugs.gnu.org, shy <mail_hysong <at> 163.com>
Subject: Re: bug#40220: date command set linux epoch time failed
Date: Sun, 29 Mar 2020 22:32:44 -0600

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 +0000

Bob

Message #27 received at 40220-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bob Proulx <bob <at> proulx.com>, 40220-done <at> debbugs.gnu.org,
 shy <mail_hysong <at> 163.com>
Subject: Re: bug#40220: date command set linux epoch time failed
Date: Sun, 29 Mar 2020 23:26:30 -0700

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'.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.