Pádraig Brady wrote: > On 07/27/2012 05:56 PM, Jim Meyering wrote: ... >> When I try to trigger such misbehavior, timeout seems to work fine >> on a system (Fedora 17) with a working timer_settime function: >> >> $ timeout 2 date --set=$(LC_ALL=C date -d 10\ sec +@%s); echo $? >> 0 >> >> I.e., when timeout's child terminates, the clock says >> 10 seconds have elapsed, yet it exits 0, because the >> duration was less than 2 seconds. >> >> I'm using the timeout from coreutils-8.17, but nothing >> has changed in this area since before 8.13. >> >> I even rebuilt my timeout binary, simulating no timer_settime >> function so that it would take the alarm-using path. Same result. > > Note timeout(1) currently uses timer_create(CLOCK_REALTIME). > That could jump and cause signals to fire. > Though I can't reproduce here, 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 > > I was wondering about using CLOCK_MONOTONIC instead, > though I'd need to test how that functions over a suspend/resume. > I suspect it only counts up while the system is running. > Maybe we should default to system running time, rather than > wall clock time, though then we'd have to look at/document > the inconsistency on systems without CLOCK_MONOTONIC.
Yes, using CLOCK_MONOTONIC looked tempting to me, too, but finding no problem with the use of CLOCK_REALTIME, I was leery of switching. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
