Not worried, it is legitimately a problem for us to the point we are currently patching bash to use the monotonic clock for seconds. It times out stuff in our boot process which executes normally after the time sync has completed and jumped the clock forward. Rght now, we are just patching bash until we can fix all of our uses of $SECONDS. I don't really have a preference for how this gets exposed (updating SECONDS to use the monotonic timer, adding a new variable like MONOSECONDS, or some other call to get monotonic time via clock_gettime).
On Fri, Mar 24, 2023 at 11:41 AM Chet Ramey <chet.ra...@case.edu> wrote: > On 3/23/23 8:42 PM, William Kennington via Bug reports for the GNU Bourne > Again SHell wrote: > > We have systems that start off with inaccurate clocks and at some point > > after the boot process synchronize with the network and jump forward in > > time. This has the potential to break any scripts that are sitting in > > loops, calculating a timeout based on the $SECONDS variable. The current > > behavior using realtime instead of monotime is surprising to us. > > So the system jumps forward in time at some random point, after the shell > script has started and $SECONDS has been initialized. You're worried that > these scripts will hit their timeout too quickly? > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/ > >
