GNU bug report logs - #12248
sleep: use realtime seconds, not relative seconds (be

Previous Next

To reply to this bug, email your comments to 12248 AT debbugs.gnu.org.

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

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

From: Albrecht Frenzel <ajfrenzel <at> web.de>
To: bug-coreutils <at> gnu.org
Subject: sleep is not arware of suspend mode
Date: Tue, 21 Aug 2012 15:05:47 +0200

sleep (GNU coreutils) 8.13 on ubuntu 12.04 (64 bit) is not aware of 
suspend mode:

	sleep 5m
	<switch system to suspend mode for 2m>
	<wake up>

The shell will be resumed after 7m

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

From: Philipp Thomas <pth <at> suse.de>
To: bug-coreutils <at> gnu.org
Subject: Re: bug#12248: sleep is not arware of suspend mode
Date: Tue, 21 Aug 2012 18:15:27 +0200

* Albrecht Frenzel (ajfrenzel <at> web.de) [20120821 18:05]:

> 	sleep 5m
> 	<switch system to suspend mode for 2m>
> 	<wake up>
> 
> The shell will be resumed after 7m

That's how it should be. The complete system is frozen and after resuming
continue where they were were stopped.

Philipp

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

From: Bob Proulx <bob <at> proulx.com>
To: Philipp Thomas <pth <at> suse.de>
Cc: 12248 <at> debbugs.gnu.org
Subject: Re: bug#12248: sleep is not arware of suspend mode
Date: Tue, 21 Aug 2012 10:58:56 -0600

tag 12248 + notabug
close 12248
thanks

Philipp Thomas wrote:
> Albrecht Frenzel wrote:
> > 	sleep 5m
> > 	<switch system to suspend mode for 2m>
> > 	<wake up>
> > 
> > The shell will be resumed after 7m
> 
> That's how it should be. The complete system is frozen and after resuming
> continue where they were were stopped.

Correct.  That is the expected behavior.  Therefore I am closing this
bug.

Bob

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bob Proulx <bob <at> proulx.com>
Cc: 12248 <at> debbugs.gnu.org, Albrecht Frenzel <ajfrenzel <at> web.de>
Subject: Re: bug#12248: sleep is not arware of suspend mode
Date: Tue, 21 Aug 2012 13:50:51 -0700

On 08/21/2012 09:58 AM, Bob Proulx wrote:
> That is the expected behavior.

It's not the behavior *I* expect.  I expect
'sleep' to use realtime seconds, not seconds
of some arbitrary clock that's way far from
real time.

I've taken the liberty of reopening this one,
for further discussion.

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

From: Bob Proulx <bob <at> proulx.com>
To: 12248 <at> debbugs.gnu.org, Albrecht Frenzel <ajfrenzel <at> web.de>
Subject: Re: bug#12248: sleep is not arware of suspend mode
Date: Tue, 21 Aug 2012 15:02:38 -0600

Paul Eggert wrote:
> Bob Proulx wrote:
> > That is the expected behavior.
> 
> It's not the behavior *I* expect.  I expect
> 'sleep' to use realtime seconds, not seconds
> of some arbitrary clock that's way far from
> real time.

Sleep has always been a pause in relative time from when the call is
made to when it returns.  Implementations have varied (signals,
select, etc.) each with various issues causing a move from one to the
other method.  But if the system suspends then all processes suspend
together.  When the system wakes up then all processes proceed
together from the point where they left off when suspending.  I think
anything else is going to create a lot of problems.

I could see a big problem for many processes on the system if when the
system resumes from suspend that all of the sleeping processes "all go
off at once".  It would cause a huge spike in system load as all of
them fired all at one time.  Granted that most sleeping processes are
going to be sleeping in C code and no change to the coreutils sleep
program will affect them.  But any scripts that are using sleep would
be affected.

Also, the reason for sleep is often to add skew between two events.
If upon wakeup all of the sleeping processes are all triggered then
all relative skew will have been removed.  Worse the wakeup would act
as a synchronization point causing all of the sleeping processes to be
deskewed.

But I can definitely see that sleeping until a particular time would
be useful behavior.  But that would be such as large expansion of code
and behavior that I think it should warrant a different program rather
than expand sleep that much.

Should we create a new command that sleeps until a particular system
time?

  sleepuntil --date="now + 30 minutes"

Bob

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

From: Eric Blake <eblake <at> redhat.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12248 <at> debbugs.gnu.org, Albrecht Frenzel <ajfrenzel <at> web.de>,
	Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#12248: sleep is not arware of suspend mode
Date: Tue, 21 Aug 2012 15:03:15 -0600

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

On 08/21/2012 02:50 PM, Paul Eggert wrote:
> On 08/21/2012 09:58 AM, Bob Proulx wrote:
>> That is the expected behavior.
> 
> It's not the behavior *I* expect.  I expect
> 'sleep' to use realtime seconds, not seconds
> of some arbitrary clock that's way far from
> real time.

In fact, I think both modes have their use, and that we probably ought
to provide an option to choose between absolute wall clock deadline
(stable realtime sleep even if the processor time jumps forwards or
backwards or has gaps due to suspend) vs. elapsed relative processor
time (where changing the processor clock can lengthen or shorten the
sleep duration).  If we do add code to support multiple flavors of sleep
durations, I'd probably lean towards absolute wall time as the default.

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

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

From: Albrecht Frenzel <ajfrenzel <at> web.de>
To: Bob Proulx <bob <at> proulx.com>
Cc: 12248 <at> debbugs.gnu.org
Subject: Re: bug#12248: sleep is not arware of suspend mode
Date: Wed, 22 Aug 2012 00:31:12 +0200

> Granted that most sleeping processes are
> going to be sleeping in C code and no change to the coreutils sleep
> program will affect them.

At script level, I would expect real time behaviour. At system level 
in C code, both is possible.

Remember leap seconds.

Albrecht

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 12248 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
	Albrecht Frenzel <ajfrenzel <at> web.de>, Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#12248: sleep is not arware of suspend mode
Date: Wed, 22 Aug 2012 01:15:31 +0100

On 08/21/2012 10:03 PM, Eric Blake wrote:
> On 08/21/2012 02:50 PM, Paul Eggert wrote:
>> On 08/21/2012 09:58 AM, Bob Proulx wrote:
>>> That is the expected behavior.
>>
>> It's not the behavior *I* expect.  I expect
>> 'sleep' to use realtime seconds, not seconds
>> of some arbitrary clock that's way far from
>> real time.
> 
> In fact, I think both modes have their use, and that we probably ought
> to provide an option to choose between absolute wall clock deadline
> (stable realtime sleep even if the processor time jumps forwards or
> backwards or has gaps due to suspend) vs. elapsed relative processor
> time (where changing the processor clock can lengthen or shorten the
> sleep duration).  If we do add code to support multiple flavors of sleep
> durations, I'd probably lean towards absolute wall time as the default.

I agree that either behavior could be required.
The default though should probably stay as is.
I.E. when the system suspends, the timeout suspends too.
Changing to "wall clock time" would require an option,
as that can jump around due to suspend, ntp, ...

We had this discussion recently also, in relation to timeout(1).

timeout(1) currently uses timer_create(CLOCK_REALTIME).
According to docs¹, that should jump due to settime()/settimeofday()/resume
though I can't reproduce here with a resume, or even when pushing the
updated system clock down to the hardware:

# timeout 3 sh -c 'date --set=$(LC_ALL=C date -d 10\ sec +@%s); hwclock -w; sleep 1'
# echo $?
0

Here is some pertinent info from nanosleep(2) (used by sleep(1)):
   POSIX.1  specifies  that  nanosleep()  should  measure time against the
   CLOCK_REALTIME clock.  However,  Linux  measures  the  time  using  the
   CLOCK_MONOTONIC  clock.   This  probably  does  not  matter,  since the
   POSIX.1 specification  for  clock_settime(2)  says  that  discontinuous
   changes in CLOCK_REALTIME should not affect nanosleep():
        Setting  the  value  of  the CLOCK_REALTIME clock via clock_set‐
        time(2) shall have no effect on threads that are blocked waiting
        for a relative time service based upon this clock, including the
        nanosleep() function; ...   Consequently,  these  time  services
        shall expire when the requested relative interval elapses, inde‐
        pendently of the new or old value of the clock.
Maybe the kernel is incorrectly implementing this POSIX clause
for our interval timer. Perhaps we need to specify TIMER_ABSTIME
to timer_settime to avoid that? I need to look into that further.

Anyway to explicitly select with an option, a "running time" rather than
"wall time" we could use CLOCK_MONOTONIC (or CLOCK_MONOTONIC_RAW on newer kernels).
That's not always available though, so then we'd have to look at/document
the inconsistency on systems without CLOCK_MONOTONIC.

Note also that timeout currently doesn't handle a SIGSTOP or SIGTSTP specially,
as I was thinking it should count down system running time rather
than job running time, as that is dependent on many factors.

cheers,
Pádraig.

¹ http://juliusdavies.ca/posix_clocks/clock_realtime_linux_faq.html

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 12248 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>,
	Albrecht Frenzel <ajfrenzel <at> web.de>, Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#12248: sleep is not arware of suspend mode
Date: Tue, 21 Aug 2012 20:18:26 -0700

On 08/21/2012 05:15 PM, Pádraig Brady wrote:
> I agree that either behavior could be required.
> The default though should probably stay as is.
> I.E. when the system suspends, the timeout suspends too.

But that's not what 'sleep' does, on systems where
'nanosleep' uses real time, which is what POSIX
specifies.

The Linux kernel uses CLOCK_MONOTONIC for nanosleep,
as opposed to the POSIX-specified CLOCK_REALTIME.
This is an infelicity.  It'd be nicer if 'sleep'
acted as if it were using a realtime clock when
running under the Linux kernel, just as 'sleep'
does on other POSIX systems.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12248 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>,
	Albrecht Frenzel <ajfrenzel <at> web.de>, Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#12248: sleep is not arware of suspend mode
Date: Wed, 22 Aug 2012 09:55:42 +0100

On 08/22/2012 04:18 AM, Paul Eggert wrote:
> On 08/21/2012 05:15 PM, Pádraig Brady wrote:
>> I agree that either behavior could be required.
>> The default though should probably stay as is.
>> I.E. when the system suspends, the timeout suspends too.
> 
> But that's not what 'sleep' does, on systems where
> 'nanosleep' uses real time, which is what POSIX
> specifies.
> 
> The Linux kernel uses CLOCK_MONOTONIC for nanosleep,
> as opposed to the POSIX-specified CLOCK_REALTIME.
> This is an infelicity.  It'd be nicer if 'sleep'
> acted as if it were using a realtime clock when
> running under the Linux kernel, just as 'sleep'
> does on other POSIX systems.

POSIX states that:

"Setting  the  value  of  the CLOCK_REALTIME clock via clock_set‐
 time(2) shall have no effect on threads that are blocked waiting
 for a relative time service based upon this clock"

So I'm guessing that Linux is just using CLOCK_MONOTONIC
for consistency so that nanosleep() behaves the same,
whether or not CLOCK_REALTIME jumps due to suspend/resume
or settime().

If other system's nanosleep() are dependent on settime()
then that seems in contravention of POSIX.
If other system's nanosleep() are dependent on suspend/resume
then that seems inconsistent.

It seems like we need to specify a TIMER_ABSTIME via
clock_nanosleep() or timer_settime() to both provide
that behavior as an option and possibly reduce inconsistency
between systems.

cheers,
Pádraig.

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

From: Julian Bradfield <jcb <at> inf.ed.ac.uk>
To: 12248 <at> debbugs.gnu.org
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, Eric Blake <eblake <at> redhat.com>,
	Bob Proulx <bob <at> proulx.com>, Albrecht Frenzel <ajfrenzel <at> web.de>
Subject: Re: sleep is not arware of suspend mode
Date: Fri, 18 Jan 2013 07:45:49 +0000

I've just come across this thread, as I was trying to work out who was
responsible for this (IMHO) undoubted bug. I wanted to respond to
Pádraig's last comment.

Pádraig said:

> POSIX states that:
> 
> "Setting  the  value  of  the CLOCK_REALTIME clock via clock_set-
>  time(2) shall have no effect on threads that are blocked waiting
>  for a relative time service based upon this clock"

I strongly suspect that this is an infelicity in the expression of the
intended specification. Obviously relative CLOCK_REALTIME waits should
not be be affected if the time changes because it's been set
wrong. But that's a different matter from changing it because real
time has elapsed without it noticing. Posix was not really written
with modern systems in mind.
(Leaving aside the question of whether adjusting the time after resume
is done by userspace calling clock_settime() !)


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Previous Next

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