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

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

Re: strange time problem with bullseye

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: strange time problem with bullseye Teemu Likonen <tlikonen@iki.fi> - 2024-03-06 06:40 +0100
    Re: strange time problem with bullseye Greg Wooledge <greg@wooledge.org> - 2024-03-06 13:10 +0100
      Re: strange time problem with bullseye Jeffrey Walton <noloader@gmail.com> - 2024-03-06 19:10 +0100
      Re: strange time problem with bullseye David Wright <deblis@lionunicorn.co.uk> - 2024-03-06 20:30 +0100
    Re: strange time problem with bullseye "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-03-06 18:20 +0100
      Re: strange time problem with bullseye Teemu Likonen <tlikonen@iki.fi> - 2024-03-06 18:40 +0100
        Re: strange time problem with bullseye Greg Wooledge <greg@wooledge.org> - 2024-03-06 18:50 +0100
          Re: strange time problem with bullseye gene heskett <gheskett@shentel.net> - 2024-03-07 00:00 +0100
            Re: strange time problem with bullseye Greg Wooledge <greg@wooledge.org> - 2024-03-07 00:10 +0100
              Re: strange time problem with bullseye gene heskett <gheskett@shentel.net> - 2024-03-07 02:40 +0100
                Re: strange time problem with bullseye John Hasler <john@sugarbit.com> - 2024-03-07 03:10 +0100
                  Re: strange time problem with bullseye <tomas@tuxteam.de> - 2024-03-07 06:30 +0100
                    Re: strange time problem with bullseye gene heskett <gheskett@shentel.net> - 2024-03-07 14:40 +0100
                      Re: strange time problem with bullseye <tomas@tuxteam.de> - 2024-03-07 14:50 +0100
                        Re: strange time problem with bullseye Jeffrey Walton <noloader@gmail.com> - 2024-03-07 17:20 +0100
                          Re: strange time problem with bullseye gene heskett <gheskett@shentel.net> - 2024-03-07 17:40 +0100
                      Re: strange time problem with bullseye Teemu Likonen <tlikonen@iki.fi> - 2024-03-07 15:10 +0100
                        Re: strange time problem with bullseye "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-03-07 20:40 +0100
                          Re: strange time problem with bullseye Greg Wooledge <greg@wooledge.org> - 2024-03-07 20:50 +0100
                            Re: strange time problem with bullseye "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-03-08 18:30 +0100
                      Re: strange time problem with bullseye Greg Wooledge <greg@wooledge.org> - 2024-03-07 17:00 +0100
                        Re: strange time problem with bullseye gene heskett <gheskett@shentel.net> - 2024-03-07 17:40 +0100
                          Re: strange time problem with bullseye/buster David Wright <deblis@lionunicorn.co.uk> - 2024-03-07 18:20 +0100
                            Re: strange time problem with bullseye/buster gene heskett <gheskett@shentel.net> - 2024-03-08 01:20 +0100
                              Re: strange time problem with bullseye/buster David Wright <deblis@lionunicorn.co.uk> - 2024-03-08 03:40 +0100
                                Re: strange time problem with bullseye/buster gene heskett <gheskett@shentel.net> - 2024-03-08 04:30 +0100
                              Re: strange time problem with bullseye/buster Max Nikulin <manikulin@gmail.com> - 2024-03-08 17:20 +0100
                Re: strange time problem with bullseye Greg Wooledge <greg@wooledge.org> - 2024-03-07 03:40 +0100
                  Re: strange time problem with bullseye <tomas@tuxteam.de> - 2024-03-07 06:30 +0100
          Re: strange time problem with bullseye "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-03-07 20:20 +0100
            Re: strange time problem with bullseye Dan Ritter <dsr@randomstring.org> - 2024-03-07 20:50 +0100
            Re: strange time problem with bullseye gene heskett <gheskett@shentel.net> - 2024-03-08 01:30 +0100
      Re: strange time problem with bullseye Jeffrey Walton <noloader@gmail.com> - 2024-03-06 18:50 +0100

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

#268141

On Thu, Mar 07, 2024 at 08:31:16AM -0500, gene heskett wrote:
> So I purged ntpsec and re-installed chrony which I had done once before with
> no luck but this time timedatectl was stopped and it worked!
> 
> Now, how do I assure timedatectl stays stopped on a reboot?

Which version of Debian is this?  I'm guessing it's fairly recent,
because ntpsec is fairly recent.

In the most recent version or two, systemd-timesyncd is a separate
package, and it cannot coexist with chrony (they both provide the
"time-daemon" virtual package).  So, if this is Debian 12 (maybe 11
also, dunno about older), then when you installed either ntpsec or
chrony, it should have removed the systemd-timesyncd package.

You should be able to verify that the systemd-timesyncd package is
removed.

In some older versions of Debian, systemd-timesyncd was part of the
systemd package, and was always installed, even if you installed ntp
or chrony.  In these versions, the systemd unit file for timesync
had checks for the existence of the binaries belonging to ntp, chrony
and openntpd, and would prevent timesync from running if any of those
was found.

I don't remember which version did which thing.

And of course, if you are not actually running Debian, then all bets are
off.  You're on your own with Armbian, Raspbian, etc.

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

#268144

On 3/7/24 10:59, Greg Wooledge wrote:
> On Thu, Mar 07, 2024 at 08:31:16AM -0500, gene heskett wrote:
>> So I purged ntpsec and re-installed chrony which I had done once before with
>> no luck but this time timedatectl was stopped and it worked!
>>
>> Now, how do I assure timedatectl stays stopped on a reboot?
> 
> Which version of Debian is this?  I'm guessing it's fairly recent,
> because ntpsec is fairly recent.
> 
> In the most recent version or two, systemd-timesyncd is a separate
> package, and it cannot coexist with chrony (they both provide the
> "time-daemon" virtual package).  So, if this is Debian 12 (maybe 11
> also, dunno about older), then when you installed either ntpsec or
> chrony, it should have removed the systemd-timesyncd package.
> 
> You should be able to verify that the systemd-timesyncd package is
> removed.
> 

> In some older versions of Debian, systemd-timesyncd was part of the
> systemd package, and was always installed, even if you installed ntp
> or chrony.  In these versions, the systemd unit file for timesync
> had checks for the existence of the binaries belonging to ntp, chrony
> and openntpd, and would prevent timesync from running if any of those
> was found.
> 
> I don't remember which version did which thing.
> 
> And of course, if you are not actually running Debian, then all bets are
> off.  You're on your own with Armbian, Raspbian, etc.
> 
> .
and because the printer is arm stuff, its old armbian buster vintage.
mks@mkspi:/etc/init.d$ sudo apt purge systemd-timesyncd
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'systemd-timesyncd' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
mks@mkspi:/etc/init.d$
yet timedatectl is still there and shows:
mks@mkspi:/etc/init.d$ timedatectl
                Local time: Thu 2024-03-07 11:15:53 EST
            Universal time: Thu 2024-03-07 16:15:53 UTC
                  RTC time: Thu 2024-03-07 11:04:39
                 Time zone: America/New_York (EST, -0500)
System clock synchronized: no
               NTP service: inactive
           RTC in local TZ: no
mks@mkspi:/etc/init.d$
And the local time shown above is correct to the second.

Thanks Greg, take care & stay well.

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

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

#268145 — Re: strange time problem with bullseye/buster

On Thu 07 Mar 2024 at 11:29:47 (-0500), gene heskett wrote:
> On 3/7/24 10:59, Greg Wooledge wrote:

> > You should be able to verify that the systemd-timesyncd package is
> > removed.
> > 
> 
> > In some older versions of Debian, systemd-timesyncd was part of the
> > systemd package, and was always installed, even if you installed ntp
> > or chrony.  In these versions, the systemd unit file for timesync
> > had checks for the existence of the binaries belonging to ntp, chrony
> > and openntpd, and would prevent timesync from running if any of those
> > was found.
> > 
> > I don't remember which version did which thing.
> > 
> > And of course, if you are not actually running Debian, then all bets are
> > off.  You're on your own with Armbian, Raspbian, etc.
> > 
> and because the printer is arm stuff, its old armbian buster vintage.
> mks@mkspi:/etc/init.d$ sudo apt purge systemd-timesyncd
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package 'systemd-timesyncd' is not installed, so not removed
> 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
> mks@mkspi:/etc/init.d$
> yet timedatectl is still there and shows:
> mks@mkspi:/etc/init.d$ timedatectl
>                Local time: Thu 2024-03-07 11:15:53 EST
>            Universal time: Thu 2024-03-07 16:15:53 UTC
>                  RTC time: Thu 2024-03-07 11:04:39
>                 Time zone: America/New_York (EST, -0500)
> System clock synchronized: no
>               NTP service: inactive
>           RTC in local TZ: no
> mks@mkspi:/etc/init.d$
> And the local time shown above is correct to the second.

Debian's buster's systemd (241) has timesyncd built-in, so you may
find that   ls -l /lib/systemd/systemd-timesyncd still finds it.

The output from timedatectl is worrying. I would monitor chrony and
check its logs to see if it it's doing anything. After all, you had
ntpsec running until a "moment" ago, so you'd hardly expect the clock
to be wrong by now.

I tried installing chrony in 2017 (jessie), and it appeared unable
to slew the clock five seconds in two days of interrupted running.

Cheers,
David.

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

#268160 — Re: strange time problem with bullseye/buster

On 3/7/24 12:19, David Wright wrote:
> On Thu 07 Mar 2024 at 11:29:47 (-0500), gene heskett wrote:
>> On 3/7/24 10:59, Greg Wooledge wrote:
> 
>>> You should be able to verify that the systemd-timesyncd package is
>>> removed.
>>>
>>
>>> In some older versions of Debian, systemd-timesyncd was part of the
>>> systemd package, and was always installed, even if you installed ntp
>>> or chrony.  In these versions, the systemd unit file for timesync
>>> had checks for the existence of the binaries belonging to ntp, chrony
>>> and openntpd, and would prevent timesync from running if any of those
>>> was found.
>>>
>>> I don't remember which version did which thing.
>>>
>>> And of course, if you are not actually running Debian, then all bets are
>>> off.  You're on your own with Armbian, Raspbian, etc.
>>>
>> and because the printer is arm stuff, its old armbian buster vintage.
>> mks@mkspi:/etc/init.d$ sudo apt purge systemd-timesyncd
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> Package 'systemd-timesyncd' is not installed, so not removed
>> 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
>> mks@mkspi:/etc/init.d$
>> yet timedatectl is still there and shows:
>> mks@mkspi:/etc/init.d$ timedatectl
>>                 Local time: Thu 2024-03-07 11:15:53 EST
>>             Universal time: Thu 2024-03-07 16:15:53 UTC
>>                   RTC time: Thu 2024-03-07 11:04:39
>>                  Time zone: America/New_York (EST, -0500)
>> System clock synchronized: no
>>                NTP service: inactive
>>            RTC in local TZ: no
>> mks@mkspi:/etc/init.d$
>> And the local time shown above is correct to the second.
> 
> Debian's buster's systemd (241) has timesyncd built-in, so you may
> find that   ls -l /lib/systemd/systemd-timesyncd still finds it.
> 
> The output from timedatectl is worrying. I would monitor chrony and
> check its logs to see if it it's doing anything. After all, you had
> ntpsec running until a "moment" ago, so you'd hardly expect the clock
> to be wrong by now.

At the instant I removed ntpsec and minute later whem I re-installed 
chrony, the time on that printer was around 20 hours stale. By about a 
minute after chrony started, which the install did, time was synchronized.

And still is. Somehow, it resurrected the customized
/etc/chrony/chrony.conf which pointed it at this machines ntpsec server. 
So I didn't have to re-invent that wheel. It just Worked. Memory in the 
u-sd card? IDK.

I have NDI how to extract chrony's logs from journalctl.

> I tried installing chrony in 2017 (jessie), and it appeared unable
> to slew the clock five seconds in two days of interrupted running.
> 
> Cheers,
> David.
> 
Thank you David, take care & stay well.

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

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

#268165 — Re: strange time problem with bullseye/buster

On Thu 07 Mar 2024 at 19:17:02 (-0500), gene heskett wrote:
> On 3/7/24 12:19, David Wright wrote:
> > On Thu 07 Mar 2024 at 11:29:47 (-0500), gene heskett wrote:
> > > On 3/7/24 10:59, Greg Wooledge wrote:
> > 
> > > > You should be able to verify that the systemd-timesyncd package is
> > > > removed.
> > > > 
> > > 
> > > > In some older versions of Debian, systemd-timesyncd was part of the
> > > > systemd package, and was always installed, even if you installed ntp
> > > > or chrony.  In these versions, the systemd unit file for timesync
> > > > had checks for the existence of the binaries belonging to ntp, chrony
> > > > and openntpd, and would prevent timesync from running if any of those
> > > > was found.
> > > > 
> > > > I don't remember which version did which thing.
> > > > 
> > > > And of course, if you are not actually running Debian, then all bets are
> > > > off.  You're on your own with Armbian, Raspbian, etc.
> > > > 
> > > and because the printer is arm stuff, its old armbian buster vintage.
> > > mks@mkspi:/etc/init.d$ sudo apt purge systemd-timesyncd
> > > Reading package lists... Done
> > > Building dependency tree
> > > Reading state information... Done
> > > Package 'systemd-timesyncd' is not installed, so not removed
> > > 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
> > > mks@mkspi:/etc/init.d$
> > > yet timedatectl is still there and shows:
> > > mks@mkspi:/etc/init.d$ timedatectl
> > >                 Local time: Thu 2024-03-07 11:15:53 EST
> > >             Universal time: Thu 2024-03-07 16:15:53 UTC
> > >                   RTC time: Thu 2024-03-07 11:04:39
> > >                  Time zone: America/New_York (EST, -0500)
> > > System clock synchronized: no
> > >                NTP service: inactive
> > >            RTC in local TZ: no
> > > mks@mkspi:/etc/init.d$
> > > And the local time shown above is correct to the second.
> > 
> > Debian's buster's systemd (241) has timesyncd built-in, so you may
> > find that   ls -l /lib/systemd/systemd-timesyncd still finds it.
> > 
> > The output from timedatectl is worrying. I would monitor chrony and
> > check its logs to see if it it's doing anything. After all, you had
> > ntpsec running until a "moment" ago, so you'd hardly expect the clock
> > to be wrong by now.
> 
> At the instant I removed ntpsec and minute later whem I re-installed
> chrony, the time on that printer was around 20 hours stale. By about a
> minute after chrony started, which the install did, time was
> synchronized.
> 
> And still is. Somehow, it resurrected the customized
> /etc/chrony/chrony.conf which pointed it at this machines ntpsec
> server. So I didn't have to re-invent that wheel. It just Worked.
> Memory in the u-sd card? IDK.
> 
> I have NDI how to extract chrony's logs from journalctl.

You could run these commands as an ordinary user instead:

  $ chronyc sources
  $ chronyc sourcestats
  $ chronyc tracking

which will give you an idea of what it is doing.

Cheers,
David.

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

#268166 — Re: strange time problem with bullseye/buster

On 3/7/24 21:30, David Wright wrote:
> On Thu 07 Mar 2024 at 19:17:02 (-0500), gene heskett wrote:
>> On 3/7/24 12:19, David Wright wrote:
>>> On Thu 07 Mar 2024 at 11:29:47 (-0500), gene heskett wrote:
>>>> On 3/7/24 10:59, Greg Wooledge wrote:
>>>
>>>>> You should be able to verify that the systemd-timesyncd package is
>>>>> removed.
>>>>>
>>>>
>>>>> In some older versions of Debian, systemd-timesyncd was part of the
>>>>> systemd package, and was always installed, even if you installed ntp
>>>>> or chrony.  In these versions, the systemd unit file for timesync
>>>>> had checks for the existence of the binaries belonging to ntp, chrony
>>>>> and openntpd, and would prevent timesync from running if any of those
>>>>> was found.
>>>>>
>>>>> I don't remember which version did which thing.
>>>>>
>>>>> And of course, if you are not actually running Debian, then all bets are
>>>>> off.  You're on your own with Armbian, Raspbian, etc.
>>>>>
>>>> and because the printer is arm stuff, its old armbian buster vintage.
>>>> mks@mkspi:/etc/init.d$ sudo apt purge systemd-timesyncd
>>>> Reading package lists... Done
>>>> Building dependency tree
>>>> Reading state information... Done
>>>> Package 'systemd-timesyncd' is not installed, so not removed
>>>> 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
>>>> mks@mkspi:/etc/init.d$
>>>> yet timedatectl is still there and shows:
>>>> mks@mkspi:/etc/init.d$ timedatectl
>>>>                  Local time: Thu 2024-03-07 11:15:53 EST
>>>>              Universal time: Thu 2024-03-07 16:15:53 UTC
>>>>                    RTC time: Thu 2024-03-07 11:04:39
>>>>                   Time zone: America/New_York (EST, -0500)
>>>> System clock synchronized: no
>>>>                 NTP service: inactive
>>>>             RTC in local TZ: no
>>>> mks@mkspi:/etc/init.d$
>>>> And the local time shown above is correct to the second.
>>>
>>> Debian's buster's systemd (241) has timesyncd built-in, so you may
>>> find that   ls -l /lib/systemd/systemd-timesyncd still finds it.
>>>
>>> The output from timedatectl is worrying. I would monitor chrony and
>>> check its logs to see if it it's doing anything. After all, you had
>>> ntpsec running until a "moment" ago, so you'd hardly expect the clock
>>> to be wrong by now.
>>
>> At the instant I removed ntpsec and minute later whem I re-installed
>> chrony, the time on that printer was around 20 hours stale. By about a
>> minute after chrony started, which the install did, time was
>> synchronized.
>>
>> And still is. Somehow, it resurrected the customized
>> /etc/chrony/chrony.conf which pointed it at this machines ntpsec
>> server. So I didn't have to re-invent that wheel. It just Worked.
>> Memory in the u-sd card? IDK.
>>
>> I have NDI how to extract chrony's logs from journalctl.
> 
> You could run these commands as an ordinary user instead:
> 
>    $ chronyc sources
>    $ chronyc sourcestats
>    $ chronyc tracking
> 
> which will give you an idea of what it is doing.
> 
> Cheers,
> David.
> 
> .
mks@mkspi:/etc/init.d$ chronyc tracking
Reference ID    : C0A84703 (coyote.coyote.den)
Stratum         : 4
Ref time (UTC)  : Fri Mar 08 03:23:48 2024
System time     : 0.000006175 seconds slow of NTP time
Last offset     : -0.000005491 seconds
RMS offset      : 0.000007778 seconds
Frequency       : 6.590 ppm slow
Residual freq   : -0.002 ppm
Skew            : 0.036 ppm
Root delay      : 0.034696314 seconds
Root dispersion : 0.054448538 seconds
Update interval : 64.5 seconds
Leap status     : Normal

Looks good to me. ;o)>

Thanks David. Take care & stay well.

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

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

#268177 — Re: strange time problem with bullseye/buster

On 08/03/2024 07:17, gene heskett wrote:
> I have NDI how to extract chrony's logs from journalctl.

- man journalctl,
- docs listed on the systemd web site.

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

#268123

On Wed, Mar 06, 2024 at 08:33:37PM -0500, gene heskett wrote:
> no place in the ntpsec docs, nor the chrony docs
> does it show the ability to slam the current time into the SW clock on these
> arm systems at bootup's first access time.

Traditionally, this was done by the ntpdate command, which was in the
ntpdate package.

On older Debian releases, you would install both of these (ntp and
ntpdate); ntpdate would run first, slamming the clock, and then ntp
would run second, to keep the clock in sync.

A few releases ago, ntpdate was deprecated, and its slamming functionality
was absorbed into the ntp package, as long as ntp is started with the -g
option.

       -g, --panicgate
           Allow the first adjustment to be big. This option may appear an
           unlimited number of times.

           Normally, ntpd exits with a message to the system log if the offset
           exceeds the panic threshold, which is 1000 s by default. This
           option allows the time to be set to any value without restriction;
           however, this can happen only once. If the threshold is exceeded
           after that, ntpd will exit with a message to the system log. This
           option can be used with the -q and -x options. See the tinker
           configuration file directive for other options.

With ntpsec replacing ntp in Debian 12, the same options apply.  By default,
Debian runs ntpsec with the -g option, to allow the clock to be slammed
at boot time.

hobbit:~$ ps -ef | grep ntpd
ntpsec       854       1  0 Feb17 ?        00:01:17 /usr/sbin/ntpd -p /run/ntpd.pid -c /etc/ntpsec/ntp.conf -g -N -u ntpsec:ntpsec
greg      394737    1138  0 21:34 pts/0    00:00:00 grep ntpd

Your claims that "no place in the ntpsec docs ... show the ability to
slam the current time" are simply false.

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

#268125

[Multipart message — attachments visible in raw view] — view raw

On Wed, Mar 06, 2024 at 09:36:56PM -0500, Greg Wooledge wrote:
> On Wed, Mar 06, 2024 at 08:33:37PM -0500, gene heskett wrote:
> > no place in the ntpsec docs, nor the chrony docs
> > does it show the ability to slam the current time into the SW clock on these
> > arm systems at bootup's first access time.
> 
> Traditionally, this was done by the ntpdate command, which was in the
> ntpdate package.

[...]

>        -g, --panicgate

[...]

Heh. Great minds read alike :-)

But thanks for the historical background, which I didn't know.

Cheers
-- 
t

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

#268155

On Wednesday 06 March 2024 12:42:12 pm Greg Wooledge wrote:
> > How do I get the RTC to agree with the right time?
> 
> "hwclock -w" to copy the system clock to the hardware clock (RTC).  This
> should also be done during shutdown, but it doesn't hurt to do it now.
 
That seemed to do what I needed.

I don't ordinarily shut this machine down for the most part.  Every once in a while all of my swap partition gets filled up,  and then there's this continuous hard drive activity that I'm assuming is what they mean by "thrashing". The only option at that point is to get its attention with the power switch.  And then I need to go through a whole routing with bringing up what I had going,  including re-starting virtualbox and the stuff that runs in it,  etc.  If I'm lucky then I can get back the windows I had going before,  sometimes I'm not so lucky.  A system monitor I run on desktop 4 always comes up,  but on the wrong desktop and I have to move it.

The "eat all available memory" culprit seems to be firefox.  I just need to look at that system monitor every once in a while and when things start getting excessive shut firefox down and restart it.  Then I don't have the problem...

I'm not sure if I have ntp or something else running here.  (Looking...)  I don't see it in my process list.


-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

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

#268158

Roy J. Tellason, Sr. wrote: 
> I don't ordinarily shut this machine down for the most part.  Every once in a while all of my swap partition gets filled up,  and then there's this continuous hard drive activity that I'm assuming is what they mean by "thrashing". The only option at that point is to get its attention with the power switch.  And then I need to go through a whole routing with bringing up what I had going,  including re-starting virtualbox and the stuff that runs in it,  etc.  If I'm lucky then I can get back the windows I had going before,  sometimes I'm not so lucky.  A system monitor I run on desktop 4 always comes up,  but on the wrong desktop and I have to move it.
> 
> The "eat all available memory" culprit seems to be firefox.  I just need to look at that system monitor every once in a while and when things start getting excessive shut firefox down and restart it.  Then I don't have the problem...

There's a kernel feature called the OOM-killer (out of memory)
which is supposed to detect when you are running out of memory
and select a process to kill.

Did you turn it off? It would be a setting in /etc/sysctl.conf
or /etc/sysctl.d/*

If not, perhaps you have an excessive amount of slow swap for it to be happy?

 
> I'm not sure if I have ntp or something else running here.  (Looking...)  I don't see it in my process list.

Other likely candidates are systemd-timesync and chrony.

-dsr-

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

#268161

On 3/7/24 14:16, Roy J. Tellason, Sr. wrote:
> On Wednesday 06 March 2024 12:42:12 pm Greg Wooledge wrote:
>>> How do I get the RTC to agree with the right time?
>>
>> "hwclock -w" to copy the system clock to the hardware clock (RTC).  This
>> should also be done during shutdown, but it doesn't hurt to do it now.

True, but needs a sudo in front if it in my case on that armbian buster 
machine.
>   
> That seemed to do what I needed.
> 
> I don't ordinarily shut this machine down for the most part.  Every once in a while all of my swap partition gets filled up,  and then there's this continuous hard drive activity that I'm assuming is what they mean by "thrashing". The only option at that point is to get its attention with the power switch.  And then I need to go through a whole routing with bringing up what I had going,  including re-starting virtualbox and the stuff that runs in it,  etc.  If I'm lucky then I can get back the windows I had going before,  sometimes I'm not so lucky.  A system monitor I run on desktop 4 always comes up,  but on the wrong desktop and I have to move it.
> 
> The "eat all available memory" culprit seems to be firefox.  I just need to look at that system monitor every once in a while and when things start getting excessive shut firefox down and restart it.  Then I don't have the problem...
> 
> I'm not sure if I have ntp or something else running here.  (Looking...)  I don't see it in my process list.
> 
> 

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

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

#268110

On Wed, Mar 6, 2024 at 12:13 PM Roy J. Tellason, Sr. <roy@rtellason.com> wrote:
>
> On Wednesday 06 March 2024 12:37:09 am Teemu Likonen wrote:
> > * 2024-03-06 02:47:06+0800, hlyg wrote:
> >
> > > my newly-installed deb11 for amd64 shows wrong time,  it lags behind
> > > correct time by 8 hours though difference between universal and local
> > > is ok.
> >
> > It seems that you have solved the problem but here is another hint.
> > "timedatectl" is a good high-level tool for querying and adjusting time
> > settings. Without command-line arguments it prints a lot of useful info:
> >
> >     $ timedatectl
> >                    Local time: ke 2024-03-06 07:33:00 EET
> >                Universal time: ke 2024-03-06 05:33:00 UTC
> >                      RTC time: ke 2024-03-06 05:33:00
> >                     Time zone: Europe/Helsinki (EET, +0200)
> >     System clock synchronized: yes
> >                   NTP service: active
> >               RTC in local TZ: no
> >
> > See "timedatectl -h" or manual page for more info.
> >
>
> Mine shows:
>
>       Local time: Wed 2024-03-06 12:09:44 EST
>   Universal time: Wed 2024-03-06 17:09:44 UTC
>         RTC time: Wed 2024-03-06 17:20:53
>        Time zone: America/New_York (EST, -0500)
>  Network time on: yes
> NTP synchronized: no
>  RTC in local TZ: no
>
> How do I get the RTC to agree with the right time?  I don't reboot this often,  but when I do the time displayed on the onscreen clock is typically off by several minutes.

Install ntp, ntpsec or systemd-timesyncd. Once installed and time is
sync'd, run 'sudo hwclock -w'.

Also see <https://wiki.debian.org/DateTime#Installing_NTP> and
<https://manpages.debian.org/bookworm/util-linux-extra/hwclock.8.en.html>.

Jeff

[toc] | [prev] | [standalone]

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

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

csiph-web