Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #270515 > unrolled thread

How to use /etc/adjtime

Started byStefan Monnier <monnier@iro.umontreal.ca>
First post2024-06-27 18:50 +0200
Last post2024-06-29 18:50 +0200
Articles 6 on this page of 26 — 7 participants

Back to article view | Back to linux.debian.user

Contents

  How to use /etc/adjtime Stefan Monnier <monnier@iro.umontreal.ca> - 2024-06-27 18:50 +0200
    Re: How to use /etc/adjtime <tomas@tuxteam.de> - 2024-06-27 19:10 +0200
      Re: How to use /etc/adjtime Stefan Monnier <monnier@iro.umontreal.ca> - 2024-06-28 15:50 +0200
    Re: How to use /etc/adjtime David Wright <deblis@lionunicorn.co.uk> - 2024-06-28 04:30 +0200
      Re: How to use /etc/adjtime Stefan Monnier <monnier@iro.umontreal.ca> - 2024-06-28 15:50 +0200
        Re: How to use /etc/adjtime Greg Wooledge <greg@wooledge.org> - 2024-06-28 16:10 +0200
          Re: How to use /etc/adjtime David Wright <deblis@lionunicorn.co.uk> - 2024-06-28 16:40 +0200
          Re: How to use /etc/adjtime John Hasler <john@sugarbit.com> - 2024-06-28 16:50 +0200
            Re: How to use /etc/adjtime David Wright <deblis@lionunicorn.co.uk> - 2024-06-28 17:10 +0200
              Re: How to use /etc/adjtime John Hasler <john@sugarbit.com> - 2024-06-28 18:20 +0200
                Re: How to use /etc/adjtime David Wright <deblis@lionunicorn.co.uk> - 2024-06-28 21:10 +0200
                  Re: How to use /etc/adjtime John Hasler <john@sugarbit.com> - 2024-06-28 22:10 +0200
                    Re: How to use /etc/adjtime David Wright <deblis@lionunicorn.co.uk> - 2024-06-30 06:50 +0200
                  Re: How to use /etc/adjtime <tomas@tuxteam.de> - 2024-06-29 07:00 +0200
                    Re: How to use /etc/adjtime David Wright <deblis@lionunicorn.co.uk> - 2024-06-30 06:50 +0200
            Re: How to use /etc/adjtime Stefan Monnier <monnier@iro.umontreal.ca> - 2024-06-28 20:50 +0200
              Re: How to use /etc/adjtime Max Nikulin <manikulin@gmail.com> - 2024-06-29 03:30 +0200
          Re: How to use /etc/adjtime Stefan Monnier <monnier@iro.umontreal.ca> - 2024-06-28 20:40 +0200
            Re: How to use /etc/adjtime Greg Wooledge <greg@wooledge.org> - 2024-06-28 21:00 +0200
              Re: How to use /etc/adjtime David Wright <deblis@lionunicorn.co.uk> - 2024-06-28 21:50 +0200
              Re: How to use /etc/adjtime Stefan Monnier <monnier@iro.umontreal.ca> - 2024-06-28 22:00 +0200
                Re: How to use /etc/adjtime Greg Wooledge <greg@wooledge.org> - 2024-06-28 22:30 +0200
                  Re: How to use /etc/adjtime Stefan Monnier <monnier@iro.umontreal.ca> - 2024-06-28 23:10 +0200
                    Re: How to use /etc/adjtime David Wright <deblis@lionunicorn.co.uk> - 2024-06-29 02:10 +0200
    Re: How to use /etc/adjtime Charles Curley <charlescurley@charlescurley.com> - 2024-06-29 06:00 +0200
      Re: How to use /etc/adjtime Charles Curley <charlescurley@charlescurley.com> - 2024-06-29 18:50 +0200

Page 2 of 2 — ← Prev page 1 [2]

#270562

FromStefan Monnier <monnier@iro.umontreal.ca>
Date2024-06-28 22:00 +0200
Message-ID<IUpVg-6hcq-19@gated-at.bofh.it>
In reply to#270556
> Yeah, except... you're assuming a workflow that is not real or reliable.
[...]
>> It is if /etc/adjtime is set properly when you go to sleep.
> You cannot assume that adjtime was updated the last time your system
> stopped running, because your system might have stopped running due to
> a crash, instead of a controlled shutdown.

Notice I wrote "sleep".  I'm concerned about the suspend+wakeup case,
not the case when you're booting up.
[ I thought I'd made it abundantly clear.  ]


        Stefan

[toc] | [prev] | [next] | [standalone]

#270566

FromGreg Wooledge <greg@wooledge.org>
Date2024-06-28 22:30 +0200
Message-ID<IUqoh-6hCH-9@gated-at.bofh.it>
In reply to#270562
On Fri, Jun 28, 2024 at 14:44:03 -0500, David Wright wrote:
> On Fri 28 Jun 2024 at 14:54:42 (-0400), Greg Wooledge wrote:
> > The *only* thing you know at boot time is what's in the HW clock, and
> > if you're really lucky, you'll be able to figure out what time zone
> > it's allegedly set to (after reading /etc/adjtime from disk).
> > 
> > hobbit:~$ cat /etc/adjtime
> > 0.000000 1708191089 0.000000
> > 1708191089
> > UTC
> > hobbit:~$ date -d @1708191089
> > Sat Feb 17 12:31:29 EST 2024
> 
> I don't think you've mentioned which package(s) you're using to
> control your system clock.

I'm using ntpsec.


On Fri, Jun 28, 2024 at 15:53:03 -0400, Stefan Monnier wrote:
> Notice I wrote "sleep".  I'm concerned about the suspend+wakeup case,
> not the case when you're booting up.
> [ I thought I'd made it abundantly clear.  ]

I'm not a laptop person.  I don't know how to fix laptop-specific issues.

And I'm pretty convinced this is a highly laptop-specific issue, disguised
as a question about /etc/adjtime.  An X-Y problem, for sure.

If I'm understanding correctly, the problem you want to solve is as
follows:

 1) You are using a laptop.

 2) Your laptop's hardware clock drifts quite notably.

 3) At times, you perform a "sleep" or "suspend" or whatever it's called.
    This period of not-running-but-not-shut-down-either lasts for long
    enough that your clock drift becomes severe.

 4) Apparently, the system clock does not advance while in this state.

 5) After going from the not-running state to the running state, your
    system clock is reinitialized from the hardware clock.  Which is
    not accurate enough for your purposes.

 6) After going from the not-running state to the running state, your
    NTP daemon does not perform a clock synchronization soon enough for
    your purposes.  User programs have already begun to run.  Or continue
    to run?  I have absolutely no idea what goes on here.

Now, for some reason, you have become fixated on the /etc/adjtime file,
which may or may not be an appropriate way to mitigate the problem.
I have doubts.

It sounds like whatever least-bad solution you end up using is going to
depend on which NTP daemon you use, and will involve configuration
thereof.  It will not be something generic to adjtime_config(5) or
hwclock(8) or util-linux.  It also won't be something generic to Debian
systems as a whole, because neither servers nor traditional desktop
computers have this issue.  It's a laptop issue.

David has said that chrony can do fancy things involving the hardware
clock.  Maybe you should investigate that solution path.

[toc] | [prev] | [next] | [standalone]

#270568

FromStefan Monnier <monnier@iro.umontreal.ca>
Date2024-06-28 23:10 +0200
Message-ID<IUr0Z-6i4V-1@gated-at.bofh.it>
In reply to#270566
>> Notice I wrote "sleep".  I'm concerned about the suspend+wakeup case,
>> not the case when you're booting up.
>> [ I thought I'd made it abundantly clear.  ]
> I'm not a laptop person.  I don't know how to fix laptop-specific issues.

FWIW, the offending machine is a desktop.
I `suspend` most of my machines, whether desktops or laptops.
Only servers never sleep.

>  1) You are using a laptop.

It's not the case, but it shouldn't make any difference anyway.
Feel free to assume it's the case.

>  2) Your laptop's hardware clock drifts quite notably.

Right.  Tho, AFAICT the same holds (to a lesser extent) of most machines.

>  3) At times, you perform a "sleep" or "suspend" or whatever it's called.
>     This period of not-running-but-not-shut-down-either lasts for long
>     enough that your clock drift becomes severe.

At least severe enough that I'd like to reduce it.

>  4) Apparently, the system clock does not advance while in this state.

While suspended, the machine's CPU is completely off.
Only the DRAM is still powered.
[ BTW, I suspect the same problem shows up for "suspend to disk" a.k.a
  hibernate where the machine might be 100% turned off while sleeping,
  but it might go through slightly different routes in the code.  ]

>  5) After going from the not-running state to the running state, your
>     system clock is reinitialized from the hardware clock.  Which is
>     not accurate enough for your purposes.

Apparently, yes.  I don't actually know how/who reads the RTC to set the
system clock upon wakeup.  Maybe `hwclock` is not involved at all, and
maybe part of this happens directly in the kernel.

>  6) After going from the not-running state to the running state, your
>     NTP daemon does not perform a clock synchronization soon enough for
>     your purposes.  User programs have already begun to run.  Or continue
>     to run?  I have absolutely no idea what goes on here.

Yes they just continue running "as if" the machine had never been turned
off (to them, it's mostly as if the scheduler had given priority to
other tasks for a *long* time).

> Now, for some reason, you have become fixated on the /etc/adjtime file,

Not at all.  I only mention that file because that's the way this
problem used to be handled during shutdown+reboot back in the SysV-init
days using `/etc/init.d/hwclock.sh`.

> It sounds like whatever least-bad solution you end up using is going to
> depend on which NTP daemon you use, and will involve configuration
> thereof.

Actually, I think The Right Solution™ should be independent from any NTP
daemon, since in order to avoid time warps you'd like to drift-adjust
the RTC time before user-level processes (like the NTP daemon) are
woken up.

> It will not be something generic to adjtime_config(5) or
> hwclock(8) or util-linux.  It also won't be something generic to Debian
> systems as a whole, because neither servers nor traditional desktop
> computers have this issue.  It's a laptop issue.

Nowadays, there's not much difference between a desktop and a laptop
(they all use the same power-saving tricks, they all support suspending
the system, ...).

The problem does not affect servers, admittedly.

> David has said that chrony can do fancy things involving the hardware
> clock.  Maybe you should investigate that solution path.

I'm trying to find out how to fix it Right, rather than how to work
around the problem (I already know how to work around the problem).

Fixing it right requires changing the code that reads the RTC time
upon wakeup.  In any case, thank you all for your help.
Apparently none of you have the answer I'm looking for, but you did help
me narrow down the scope and make more precise what I'm after.

Indeed I see now that the time is read from RTC to set system time
directly by the kernel in `kernel/time/timekeeping.c` and
`drivers/rtc/class.c`.
So The Right Solution™ apparently involves changes to the kernel.


        Stefan

[toc] | [prev] | [next] | [standalone]

#270575

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2024-06-29 02:10 +0200
Message-ID<IUtPb-6jLU-1@gated-at.bofh.it>
In reply to#270568
On Fri 28 Jun 2024 at 17:03:47 (-0400), Stefan Monnier wrote:

> > David has said that chrony can do fancy things involving the hardware
> > clock.  Maybe you should investigate that solution path.
> 
> I'm trying to find out how to fix it Right, rather than how to work
> around the problem (I already know how to work around the problem).
> 
> Fixing it right requires changing the code that reads the RTC time
> upon wakeup.  In any case, thank you all for your help.
> Apparently none of you have the answer I'm looking for, but you did help
> me narrow down the scope and make more precise what I'm after.
> 
> Indeed I see now that the time is read from RTC to set system time
> directly by the kernel in `kernel/time/timekeeping.c` and
> `drivers/rtc/class.c`.
> So The Right Solution™ apparently involves changes to the kernel.

I can only suggest what you might investigate, as the concepts are
way above my paygrade.

All the user processes are in user.slice, as seen by:

  # systemd-cgls -u user.slice

There are commands shown in   man systemctl   called
freeze and thaw (its inverse):

  freeze PATTERN...
      Freeze one or more units specified on the command line using
      cgroup freezer

      Freezing the unit will cause all processes contained within
      the cgroup corresponding to the unit to be suspended. Being
      suspended means that unit's processes won't be scheduled to
      run on CPU until thawed. Note that this command is supported
      only on systems that use unified cgroup hierarchy. Unit is
      automatically thawed just before we execute a job against the
      unit, e.g. before the unit is stopped.

So could you suspend the system by invoking a system service to
freeze the control group the appropriate unit (user.slice) first?
When the system resumes, the thawing service would be set to run
after the service that steps the clock. (Don't use slewing.)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#270578

FromCharles Curley <charlescurley@charlescurley.com>
Date2024-06-29 06:00 +0200
Message-ID<IUxpL-6lLg-1@gated-at.bofh.it>
In reply to#270515
On Thu, 27 Jun 2024 12:48:03 -0400
Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I have a machine whose RTC clock is drifting significantly and it is
> often suspended for several days.  I run NTP so the drift I see when
> I wake the machine up gets fixed by "stepping" the clock after a
> while, but that can take a while and I'd like to improve this
> intermediate situation.

It seems to me that a lot of people much smarter than I have have
wrestled with this problem for more than 50 years, and still don't have
an instantaneous solution.

Other solutions:

* Don't suspend the machine. Problem solved.

* If you must suspend the machine, bring it up some reasonable length
  of time before you require accuracy from your clock. Problem solved.

* Invest in a decent GPS receiver, and install chrony and gpsd on the
  machine. Doing so may get the system clock in synch faster; it may
  not. Doing that sort of thing is well documented on the gpsd home
  page.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#270604

FromCharles Curley <charlescurley@charlescurley.com>
Date2024-06-29 18:50 +0200
Message-ID<IUJqV-6tMD-3@gated-at.bofh.it>
In reply to#270578
On Sat, 29 Jun 2024 16:39:14 +0100
"mick.crane" <mick.crane@gmail.com> wrote:

> > * Invest in a decent GPS receiver, and install chrony and gpsd on
> > the machine. Doing so may get the system clock in synch faster; it
> > may not. Doing that sort of thing is well documented on the gpsd
> > home page.  
> 
> Wouldn't you need to know how fast the laptop is travelling?

Unless it's in low earth orbit, probably not. It may take longer to get
a fix, but that's all.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web