On Thursday 07 March 2024 02:44:42 pm Greg Wooledge wrote:
> On Thu, Mar 07, 2024 at 02:33:05PM -0500, Roy J. Tellason, Sr. wrote:
> > On Thursday 07 March 2024 09:02:44 am Teemu Likonen wrote:
> > > systemctl status systemd-timesyncd.service
> >
> > This got me some interesting results:
> >
> >
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.
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
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
> > > >
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
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
On Thu, Mar 07, 2024 at 02:33:05PM -0500, Roy J. Tellason, Sr. wrote:
> On Thursday 07 March 2024 09:02:44 am Teemu Likonen wrote:
> > systemctl status systemd-timesyncd.service
>
> This got me some interesting results:
>
> ● systemd-timesyncd.service - Network Time Synchronization
>Loaded:
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
On Thursday 07 March 2024 09:02:44 am Teemu Likonen wrote:
> systemctl status systemd-timesyncd.service
This got me some interesting results:
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled;
vendor preset:
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
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
On 3/7/24 11:18, Jeffrey Walton wrote:
On Thu, Mar 7, 2024 at 8:44 AM wrote:
On Thu, Mar 07, 2024 at 08:31:16AM -0500, gene heskett wrote:
[...]
Now, how do I assure timedatectl stays stopped on a reboot? [...]
I'll have to leave this to others more fluent in systemd-ish.
Mask the
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
On Thu, Mar 7, 2024 at 8:44 AM wrote:
>
> On Thu, Mar 07, 2024 at 08:31:16AM -0500, gene heskett wrote:
>
> [...]
> Now, how do I assure timedatectl stays stopped on a reboot? [...]
>
> I'll have to leave this to others more fluent in systemd-ish.
Mask the systemd-timesyncd service. Masking is
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
* 2024-03-07 08:31:16-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? systemd's
> docs are positively opaque
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!
great :-)
> Now, how do I assure timedatectl stays stopped on a reboot? [...]
I'll
On 3/7/24 00:22, to...@tuxteam.de wrote:
On Wed, Mar 06, 2024 at 08:06:15PM -0600, John Hasler wrote:
Look at the chronyd settime command and the chrony.conf makestep
directive. These are intended for your situation.
This from man(8) ntpd:
-g, --panicgate
Allow the first adjustment to
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
On Wed, Mar 06, 2024 at 08:06:15PM -0600, John Hasler wrote:
> Look at the chronyd settime command and the chrony.conf makestep
> directive. These are intended for your situation.
This from man(8) ntpd:
-g, --panicgate
Allow the first adjustment to be Big. This option may appear an
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
Look at the chronyd settime command and the chrony.conf makestep
directive. These are intended for your situation.
--
John Hasler
j...@sugarbit.com
Elmwood, WI USA
On 3/6/24 18:02, Greg Wooledge wrote:
On Wed, Mar 06, 2024 at 05:56:29PM -0500, gene heskett wrote:
On 3/6/24 12:42, Greg Wooledge wrote:
On Wed, Mar 06, 2024 at 12:31:46PM -0500, Roy J. Tellason, Sr. wrote:
sudo timedatectl set-ntp true
But *don't* do that if you're using some other
On Wed, Mar 06, 2024 at 05:56:29PM -0500, gene heskett wrote:
> On 3/6/24 12:42, Greg Wooledge wrote:
> > On Wed, Mar 06, 2024 at 12:31:46PM -0500, Roy J. Tellason, Sr. wrote:
> > > sudo timedatectl set-ntp true
> >
> > But *don't* do that if you're using some other NTP program instead of
>
On 3/6/24 12:42, Greg Wooledge wrote:
On Wed, Mar 06, 2024 at 12:31:46PM -0500, Roy J. Tellason, Sr. wrote:
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
On 3/6/24 13:37, Teemu Likonen wrote:
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
On Wed 06 Mar 2024 at 07:07:36 (-0500), Greg Wooledge wrote:
> On Wed, Mar 06, 2024 at 07:37:09AM +0200, Teemu Likonen wrote:
> > 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
On Wed, Mar 6, 2024 at 7:08 AM Greg Wooledge wrote:
>
> On Wed, Mar 06, 2024 at 07:37:09AM +0200, Teemu Likonen wrote:
> > 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
On Wed, Mar 6, 2024 at 12:13 PM Roy J. Tellason, Sr. 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
On Wed, Mar 06, 2024 at 12:31:46PM -0500, Roy J. Tellason, Sr. wrote:
> 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:
* 2024-03-06 12:31:46-0500, Roy J. Tellason, Sr. wrote:
> 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
>
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
On Wed, Mar 06, 2024 at 07:37:09AM +0200, Teemu Likonen wrote:
> 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:
>
> $
* 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
On Tue, Mar 5, 2024 at 7:07 PM hlyg wrote:
>
> [...]
>
> Windows shall not cause problem, i rarely use Windows
>
> i don't know if ntp is running, what's default configuration by deb11
> amd64 installer?
If you are dual booting Linux and Windows, then see
Thank Greg Wooledge! it's solved with your help
i reboot to enter bios, it use UTC
then i change 3rd line of /etc/adjtime to UTC, reboot to take effect,
time is shown correctly now
i am timezone 0800, 8 hours ahead of GMT
both /etc/localtime points to same place
On Tue, Mar 05, 2024 at 08:28:49PM +0800, hlyg wrote:
> Thank Greg Wooledge!
>
> zhou@debian:~$ date
> Wed 06 Mar 2024 04:07:02 AM CST
> zhou@debian:~$ date -u
> Tue 05 Mar 2024 08:07:07 PM UTC
>
> above is from deb11 for i386, it's correct
OK, and your time zone is 20 hours ahead of UTC, it
On 3/5/24 20:28, hlyg wrote:
Thank Greg Wooledge!
zhou@debian:~$ date
Wed 06 Mar 2024 04:07:02 AM CST
zhou@debian:~$ date -u
Tue 05 Mar 2024 08:07:07 PM UTC
above is from deb11 for i386, it's correct
zhou@debian:~$ date
Tue 05 Mar 2024 08:13:23 PM CST
zhou@debian:~$ date -u
Tue 05 Mar 2024
Thank Greg Wooledge!
zhou@debian:~$ date
Wed 06 Mar 2024 04:07:02 AM CST
zhou@debian:~$ date -u
Tue 05 Mar 2024 08:07:07 PM UTC
above is from deb11 for i386, it's correct
zhou@debian:~$ date
Tue 05 Mar 2024 08:13:23 PM CST
zhou@debian:~$ date -u
Tue 05 Mar 2024 12:13:27 PM UTC
above is from
On Wed, 6 Mar 2024 02:47:06 +0800
hlyg wrote:
> wifi connection is good, i suppose both correct time with server
> automatically
Not necessarily. You should install an NTP client if you haven't
already. I suggest systemd-timesyncd.
--
Does anybody read signatures any more?
On Wed, Mar 06, 2024 at 02:47:06AM +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.
Run the commands "date" and "date -u" and show us the output.
Then tell us what you think
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.
i am normal user, i install only from main of deb11 plus wifi adapter
firmware, though i don't install security update. i don't know where i
can
42 matches
Mail list logo
