Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #264173 > unrolled thread
| Started by | gene heskett <gheskett@shentel.net> |
|---|---|
| First post | 2023-12-04 01:50 +0100 |
| Last post | 2023-12-04 11:00 +0100 |
| Articles | 20 on this page of 99 — 17 participants |
Back to article view | Back to linux.debian.user
ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 01:50 +0100
Re: ntpsec as server questions jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-04 02:00 +0100
Re: ntpsec as server questions jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-04 02:10 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 10:00 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-04 12:00 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 12:40 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 13:20 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 17:00 +0100
Re: ntpsec as server questions Dan Purgert <dan@djph.net> - 2023-12-04 17:40 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 22:30 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-05 04:00 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 17:40 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-04 18:10 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 19:50 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-16 11:40 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 22:30 +0100
Re: ntpsec as server questions John Hasler <john@sugarbit.com> - 2023-12-04 17:40 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 22:40 +0100
Re: ntpsec as server questions Tom Furie <tom@furie.org.uk> - 2023-12-04 17:50 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 20:20 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 22:40 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 20:20 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 13:20 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-04 14:00 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 21:30 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 21:40 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-04 22:50 +0100
Re: ntpsec as server questions jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-05 00:50 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 21:30 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-04 23:20 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-05 17:40 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-05 18:10 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-06 13:30 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 14:10 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-06 16:10 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 16:50 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-06 17:20 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 17:30 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-06 17:50 +0100
Re: ntpsec as server questions Curt <curty@free.fr> - 2023-12-06 17:50 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-05 18:30 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-05 18:30 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-06 06:30 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-06 17:50 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 18:10 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-06 18:30 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 18:40 +0100
Re: ntpsec as server questions Curt <curty@free.fr> - 2023-12-06 18:50 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-06 19:00 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 19:10 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-06 19:30 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-06 21:50 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 00:20 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-07 01:20 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 01:30 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-07 01:30 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 01:40 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-07 01:50 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 02:50 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-07 06:50 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-08 03:40 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-08 04:10 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-08 05:20 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-08 13:20 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-08 18:00 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-09 12:20 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-08 13:40 +0100
Re: ntpsec as server questions <tomas@tuxteam.de> - 2023-12-08 14:20 +0100
Re: ntpsec as server questions "Thomas Schmitt" <scdbackup@gmx.net> - 2023-12-08 14:40 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-08 18:10 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-06 21:30 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 00:20 +0100
Re: ntpsec as server questions <tomas@tuxteam.de> - 2023-12-07 06:40 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-07 06:50 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-07 13:20 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 14:10 +0100
Re: ntpsec as server questions John Hasler <john@sugarbit.com> - 2023-12-07 15:30 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 15:40 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-07 17:00 +0100
Local time in databases (Re: ntpsec as server questions) Max Nikulin <manikulin@gmail.com> - 2023-12-07 16:40 +0100
Re: Local time in databases (Re: ntpsec as server questions) <tomas@tuxteam.de> - 2023-12-07 17:10 +0100
Re: Local time in databases (Re: ntpsec as server questions) Max Nikulin <manikulin@gmail.com> - 2023-12-08 03:20 +0100
Re: Local time in databases (Re: ntpsec as server questions) Nicholas Geovanis <nickgeovanis@gmail.com> - 2023-12-08 05:20 +0100
Re: Local time in databases (Re: ntpsec as server questions) <tomas@tuxteam.de> - 2023-12-08 05:40 +0100
Re: Local time in databases (Re: ntpsec as server questions) Max Nikulin <manikulin@gmail.com> - 2023-12-12 18:10 +0100
Re: Local time in databases David Wright <deblis@lionunicorn.co.uk> - 2023-12-17 06:20 +0100
Re: Local time in databases (Re: ntpsec as server questions) <tomas@tuxteam.de> - 2023-12-08 05:40 +0100
Re: ntpsec as server questions James Cloos <cloos@jhcloos.com> - 2023-12-06 22:30 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-07 06:50 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-05 04:00 +0100
Re: ntpsec as server questions Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2023-12-04 11:10 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 12:30 +0100
Re: ntpsec as server questions <tomas@tuxteam.de> - 2023-12-04 12:50 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 02:00 +0100
Re: ntpsec as server questions <tomas@tuxteam.de> - 2023-12-04 06:10 +0100
Re: ntpsec as server questions Jeffrey Walton <noloader@gmail.com> - 2023-12-04 06:30 +0100
Re: ntpsec as server questions Charles Curley <charlescurley@charlescurley.com> - 2023-12-04 07:30 +0100
Re: ntpsec as server questions Jeffrey Walton <noloader@gmail.com> - 2023-12-04 08:10 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 11:00 +0100
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2023-12-04 01:50 +0100 |
| Subject | ntpsec as server questions |
| Message-ID | <HH5jP-aTR6-1@gated-at.bofh.it> |
Greetings all;
in the docs (thanks for hiding them & doing away with manpages) it says:
-------
To make the DHCP server in the Debian package isc-dhcp-server send NTP
server
information, add a line like the following at an appropriate place:
option ntp-servers ntp1.foo.bar, ntp2.foo.bar;
----------
now I assume the foo.bar is to be replaced by something unique but
probably referencing this system doing the serving. How would this be
determined? Also "appropriate place" needs better defined.
At the other end of the local wires and switches tree on my other
machines, what is the list of debian.pool.ntp.org replaced with?
Thank you.
Cheers, Gene Heskett.
--
"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] | [next] | [standalone]
| From | jeremy ardley <jeremy.ardley@gmail.com> |
|---|---|
| Date | 2023-12-04 02:00 +0100 |
| Message-ID | <HH5tv-aTUu-1@gated-at.bofh.it> |
| In reply to | #264173 |
On 4/12/23 08:42, gene heskett wrote: > > At the other end of the local wires and switches tree on my other > machines, what is the list of debian.pool.ntp.org replaced with? To find out what ntp server(s) a system is using as compared to what may be in config files or set by dhcp client, try one or more of these: |ntpq -p timedatectl status chronyc sources or if you are hardcore sudo tcpdump -i any port 123 |||||
[toc] | [prev] | [next] | [standalone]
| From | jeremy ardley <jeremy.ardley@gmail.com> |
|---|---|
| Date | 2023-12-04 02:10 +0100 |
| Message-ID | <HH5Db-aUd0-1@gated-at.bofh.it> |
| In reply to | #264174 |
On 4/12/23 08:51, jeremy ardley wrote: > |ntpq -p timedatectl status chronyc sources or if you are hardcore > sudo tcpdump -i any port 123 ||||| Sorry, something screwed up the list One or more of: ntpq -p timedatectl status chronyc sources or if you are hardcore sudo tcpdump -i any port 123
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2023-12-04 10:00 +0100 |
| Message-ID | <HHcY1-b1Ae-1@gated-at.bofh.it> |
| In reply to | #264176 |
On 12/3/23 20:06, jeremy ardley wrote: > > On 4/12/23 08:51, jeremy ardley wrote: >> |ntpq -p timedatectl status chronyc sources or if you are hardcore >> sudo tcpdump -i any port 123 ||||| > > > Sorry, something screwed up the list > > One or more of: > > ntpq -p > > timedatectl status > > chronyc sources > > or if you are hardcore > > sudo tcpdump -i any port 123 This latter, disclosed that I was serving as a lower accuracy ntp server to anybody that came calling, probably serving a hundred or more clients in around 4 hours logging. I am surprised that dd-wrt lets port 123 thru from the network unhindered. I have this printer getting its time info from this machine's ntpsec but the chrony in the printer is ignoring /etc/timezone, stuck in PST or 4 hours behind me when comparing the output of "date". Except for the hour, its dead on to the second. This printer is running armbian buster, with apt using the debian arm repos, which have long been disabled, so I'm stuck editing what it has. There are not enough tools to build a tarball either. That messes with the estimates of time the print will finish. Chrony in the printer says its a full blown ISC client, but its ignoring the contents of /etc/timezone. Or something else is overriding /etc/timezone. Does anyone know of an override to that I might check? Thanks all > > . Cheers, Gene Heskett. -- "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]
| From | Pocket <pocket@columbus.rr.com> |
|---|---|
| Date | 2023-12-04 12:00 +0100 |
| Message-ID | <HHeQa-b3mv-7@gated-at.bofh.it> |
| In reply to | #264195 |
On 12/4/23 03:58, gene heskett wrote: > On 12/3/23 20:06, jeremy ardley wrote: >> >> On 4/12/23 08:51, jeremy ardley wrote: >>> |ntpq -p timedatectl status chronyc sources or if you are hardcore >>> sudo tcpdump -i any port 123 ||||| >> >> >> Sorry, something screwed up the list >> >> One or more of: >> >> ntpq -p >> >> timedatectl status >> >> chronyc sources >> >> or if you are hardcore >> >> sudo tcpdump -i any port 123 > > This latter, disclosed that I was serving as a lower accuracy ntp > server to anybody that came calling, probably serving a hundred or > more clients in around 4 hours logging. I am surprised that dd-wrt > lets port 123 thru from the network unhindered. > I have this printer getting its time info from this machine's ntpsec > but the chrony in the printer is ignoring /etc/timezone, stuck in PST > or 4 hours behind me when comparing the output of "date". Except for > the hour, its dead on to the second. > > This printer is running armbian buster, with apt using the debian arm > repos, which have long been disabled, so I'm stuck editing what it > has. There are not enough tools to build a tarball either. > > That messes with the estimates of time the print will finish. Chrony > in the printer says its a full blown ISC client, but its ignoring the > contents of /etc/timezone. Or something else is overriding /etc/timezone. > > Does anyone know of an override to that I might check? > > Thanks all > What does /etc/localtime say? For example on my raspberrypi 4 ls -hal /etc/localtime lrwxrwxrwx 1 root root 27 Nov 1 18:21 /etc/localtime -> /usr/share/zoneinfo/EST5EDT cat /etc/timezone America/New_York -- It's not easy to be me
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2023-12-04 12:40 +0100 |
| Message-ID | <HHfsR-b3Pk-7@gated-at.bofh.it> |
| In reply to | #264202 |
On 12/4/23 05:55, Pocket wrote: > ntpq -p I don't have that on the printer, it is running chrony. Cheers, Gene Heskett. -- "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]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-04 13:20 +0100 |
| Message-ID | <HHg5z-b4jt-9@gated-at.bofh.it> |
| In reply to | #264205 |
On Mon, Dec 04, 2023 at 06:32:38AM -0500, gene heskett wrote: > On 12/4/23 05:55, Pocket wrote: > > ntpq -p > I don't have that on the printer, it is running chrony. A quick Google search for "chrony equivalent of ntpq" gives me <https://karloluiten.nl/chrony-status-command-ntpq-p-alternative/> which says to use "chronyc sources" or "chronyc tracking".
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2023-12-04 17:00 +0100 |
| Message-ID | <HHjwt-b6Pd-1@gated-at.bofh.it> |
| In reply to | #264210 |
On 12/4/23 07:10, Greg Wooledge wrote:
> On Mon, Dec 04, 2023 at 06:32:38AM -0500, gene heskett wrote:
>> On 12/4/23 05:55, Pocket wrote:
>>> ntpq -p
>> I don't have that on the printer, it is running chrony.
>
> A quick Google search for "chrony equivalent of ntpq" gives me
> <https://karloluiten.nl/chrony-status-command-ntpq-p-alternative/>
> which says to use "chronyc sources" or "chronyc tracking".
>
Thank you Greg, both of those initially return a 506 no daemon. so:
root@mkspi:/etc# chronyc sources
506 Cannot talk to daemon
root@mkspi:/etc# chronyc tracking
506 Cannot talk to daemon
root@mkspi:/etc# /etc/init.d/chrony status
● chrony.service - chrony, an NTP client/server
Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor
preset: enabled)
Active: inactive (dead) since Mon 2023-12-04 03:21:18 PST; 4h 6min ago
Docs: man:chronyd(8)
man:chronyc(1)
man:chrony.conf(5)
Process: 30074 ExecStart=/usr/sbin/chronyd $DAEMON_OPTS (code=exited,
status=0/SUCCESS)
Process: 30078 ExecStartPost=/usr/lib/chrony/chrony-helper
update-daemon (code=exited, status=0/SUCCESS)
Main PID: 30076 (code=exited, status=0/SUCCESS)
Warning: Journal has been rotated since unit was started. Log output is
incomplete or unavailable.
root@mkspi:/etc# /etc/init.d/chrony restart
[ ok ] Restarting chrony (via systemctl): chrony.service.
root@mkspi:/etc# /etc/init.d/chrony status
● chrony.service - chrony, an NTP client/server
Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor
preset: enabled)
Active: active (running) since Mon 2023-12-04 07:28:18 PST; 3s ago
Docs: man:chronyd(8)
man:chronyc(1)
man:chrony.conf(5)
Process: 6913 ExecStart=/usr/sbin/chronyd $DAEMON_OPTS (code=exited,
status=0/SUCCESS)
Process: 6917 ExecStartPost=/usr/lib/chrony/chrony-helper
update-daemon (code=exited, status=0/SUCCESS)
Main PID: 6915 (chronyd)
Tasks: 2 (limit: 998)
Memory: 692.0K
CGroup: /system.slice/chrony.service
├─6915 /usr/sbin/chronyd -F -1
└─6916 /usr/sbin/chronyd -F -1
Dec 04 07:28:18 mkspi systemd[1]: Starting chrony, an NTP client/server...
Dec 04 07:28:18 mkspi chronyd[6915]: chronyd version 3.4 starting
(+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +…6 -DEBUG)
Dec 04 07:28:18 mkspi chronyd[6915]: Frequency -5.789 +/- 0.498 ppm read
from /var/lib/chrony/chrony.drift
Dec 04 07:28:18 mkspi chronyd[6915]: Loaded seccomp filter
Dec 04 07:28:18 mkspi systemd[1]: Started chrony, an NTP client/server.
Hint: Some lines were ellipsized, use -l to show in full.
root@mkspi:/etc# date
Mon 04 Dec 2023 07:28:49 AM PST
root@mkspi:/etc# chronyc sources
210 Number of sources = 1
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* coyote.coyote.den 2 6 17 42 -22us[ -25us] +/-
41ms
root@mkspi:/etc# chronyc tracking
Reference ID : C0A84703 (coyote.coyote.den)
Stratum : 3
Ref time (UTC) : Mon Dec 04 15:28:24 2023
System time : 0.000000003 seconds fast of NTP time
Last offset : -0.000003382 seconds
RMS offset : 0.000003382 seconds
Frequency : 5.789 ppm slow
Residual freq : +4.376 ppm
Skew : 0.498 ppm
Root delay : 0.026627216 seconds
Root dispersion : 0.027671944 seconds
Update interval : 2.0 seconds
Leap status : Normal
root@mkspi:/etc#
Thats says this machine has it hdware clock on utc.
but date is still on PTC
from mkspi, the printer:
root@mkspi:/etc# date
Mon 04 Dec 2023 07:34:59 AM PST
its 10:35 here, still 3 hours off.
So here on coyote: date -u:
Mon Dec 4 15:47:44 UTC 2023
but on mkspi: date -u:
Mon 04 Dec 2023 03:47:16 PM UTC
chrony has been restarted several times on mkspi, the printer
no errors logged in the tcpdump output.
WTH? Where is that false 12 hour offset coming from?
Cheers, Gene Heskett.
--
"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]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2023-12-04 17:40 +0100 |
| Message-ID | <HHk9b-b7oo-1@gated-at.bofh.it> |
| In reply to | #264220 |
[Multipart message — attachments visible in raw view] — view raw
On Dec 04, 2023, gene heskett wrote:
> [...]
> So here on coyote: date -u:
> Mon Dec 4 15:47:44 UTC 2023
> but on mkspi: date -u:
> Mon 04 Dec 2023 03:47:16 PM UTC
> [...]
>
> WTH? Where is that false 12 hour offset coming from?
Coyote seems to use the standard output of 'date' (in 24-hour clock
format).
mkspi /appears/ to be using an approximation of "-R" ("--rfc-email",
as set in RFC5322), though it's missing the comma between "Mon" and "04
Dec", and is set in 12-hour mode.
It's been ages since I've dug into it, but I _BELIEVE_ the LC_TIME
environment variable has an effect here. (Or had, at some point in the
past).
--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2023-12-04 22:30 +0100 |
| Message-ID | <HHoFP-bb6O-5@gated-at.bofh.it> |
| In reply to | #264225 |
On 12/4/23 11:31, Dan Purgert wrote:
> On Dec 04, 2023, gene heskett wrote:
>> [...]
>> So here on coyote: date -u:
>> Mon Dec 4 15:47:44 UTC 2023
>> but on mkspi: date -u:
>> Mon 04 Dec 2023 03:47:16 PM UTC
>> [...]
>>
>> WTH? Where is that false 12 hour offset coming from?
>
> Coyote seems to use the standard output of 'date' (in 24-hour clock
> format).
>
> mkspi /appears/ to be using an approximation of "-R" ("--rfc-email",
> as set in RFC5322), though it's missing the comma between "Mon" and "04
> Dec", and is set in 12-hour mode.
>
> It's been ages since I've dug into it, but I _BELIEVE_ the LC_TIME
> environment variable has an effect here. (Or had, at some point in the
> past).
It might well be, Dan but no man page, Set for "C" in the env output.
I redirected the /etc/localtime link to EST5EDT and fixed it, the thing
thought it was in the 3rd worst hell hole in the US, LA, CA.
>
Cheers, Gene Heskett.
--
"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]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-05 04:00 +0100 |
| Message-ID | <HHtPc-bfgU-9@gated-at.bofh.it> |
| In reply to | #264251 |
On Mon 04 Dec 2023 at 16:24:11 (-0500), gene heskett wrote:
> On 12/4/23 11:31, Dan Purgert wrote:
> > On Dec 04, 2023, gene heskett wrote:
> > > [...]
> > > So here on coyote: date -u:
> > > Mon Dec 4 15:47:44 UTC 2023
> > > but on mkspi: date -u:
> > > Mon 04 Dec 2023 03:47:16 PM UTC
> > > [...]
> > >
> > > WTH? Where is that false 12 hour offset coming from?
> >
> > Coyote seems to use the standard output of 'date' (in 24-hour clock
> > format).
> >
> > mkspi /appears/ to be using an approximation of "-R" ("--rfc-email",
> > as set in RFC5322), though it's missing the comma between "Mon" and "04
> > Dec", and is set in 12-hour mode.
> >
> > It's been ages since I've dug into it, but I _BELIEVE_ the LC_TIME
> > environment variable has an effect here. (Or had, at some point in the
> > past).
> It might well be, Dan but no man page,
They're all documented together in man locale, with examples:
$ man locale | grep -A25 EXAMPLES
EXAMPLES
$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
$ locale date_fmt
%a %b %e %H:%M:%S %Z %Y
$ locale -k date_fmt
date_fmt="%a %b %e %H:%M:%S %Z %Y"
$ locale -ck date_fmt
LC_TIME
date_fmt="%a %b %e %H:%M:%S %Z %Y"
$
Set for "C" in the env output.
> I redirected the /etc/localtime link to EST5EDT and fixed it, the
> thing thought it was in the 3rd worst hell hole in the US, LA, CA.
Please—no.
Cheers,
David.
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-04 17:40 +0100 |
| Message-ID | <HHk9b-b7oo-7@gated-at.bofh.it> |
| In reply to | #264220 |
On Mon, Dec 04, 2023 at 10:55:47AM -0500, gene heskett wrote: > root@mkspi:/etc# chronyc sources > 210 Number of sources = 1 > MS Name/IP address Stratum Poll Reach LastRx Last sample > > =============================================================================== > ^* coyote.coyote.den 2 6 17 42 -22us[ -25us] +/- > 41ms I've never used chrony, but that looks good at first glance. > root@mkspi:/etc# date > Mon 04 Dec 2023 07:34:59 AM PST > its 10:35 here, still 3 hours off. The time is *correct*, it's just being reported for a different time zone than you want. > So here on coyote: date -u: > Mon Dec 4 15:47:44 UTC 2023 > but on mkspi: date -u: > Mon 04 Dec 2023 03:47:16 PM UTC Again, both correct. > WTH? Where is that false 12 hour offset coming from? There is no 12 hour offset. One is being reported in 24-hour time, and the other in 12-hour time (it says "PM"), because of different locale definitions. All you need to do is change your system's default time zone, which on Debian involves changing the *file* /etc/timezone and the *symlink* /etc/localtime. Both are required, because some programs use one and some use the other. We've said this in like 3 other emails so far.
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-04 18:10 +0100 |
| Message-ID | <HHkCd-b7Tm-7@gated-at.bofh.it> |
| In reply to | #264227 |
On 04/12/2023 23:34, Greg Wooledge wrote:
>> WTH? Where is that false 12 hour offset coming from?
> There is no 12 hour offset. One is being reported in 24-hour time, and
> the other in 12-hour time (it says "PM"), because of different locale
> definitions.
dpkg-reconfigure locales
Or its equivalent for modified armbian. See /etc/default/locale and
https://www.debian.org/doc/manuals/debian-reference/ch09.en.html#_customized_display_of_time_and_date
"9.3.4. Customized display of time and date" and "9.5.5. System and
hardware time". I hope, no applications rely on specific locale while
parsing time or numbers.
echo "$TZ"
https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html
but ignore most of its content, use zone identifiers like America/New_York
This device may have rather outdated tzdata package. The database is
updated several times a year. Maybe your time zone has not changed since
that version was released.
I would not be surprised if this box does something fancy like sending a
request to some GeoIP database and setting timezone accordingly to
received response.
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-04 19:50 +0100 |
| Message-ID | <HHmaZ-b8Yi-1@gated-at.bofh.it> |
| In reply to | #264234 |
On Tue, Dec 05, 2023 at 12:01:35AM +0700, Max Nikulin wrote: > On 04/12/2023 23:34, Greg Wooledge wrote: > > > WTH? Where is that false 12 hour offset coming from? > > There is no 12 hour offset. One is being reported in 24-hour time, and > > the other in 12-hour time (it says "PM"), because of different locale > > definitions. > > dpkg-reconfigure locales > > Or its equivalent for modified armbian. See /etc/default/locale and > https://www.debian.org/doc/manuals/debian-reference/ch09.en.html#_customized_display_of_time_and_date That chapter talks about customizing timestamps in "ls -l" output. > "9.3.4. Customized display of time and date" and "9.5.5. System and hardware > time". Chapter 9.5.5 talks about setting the hardware clock, and recommends installing an NTP package. Neither of these chapters tells you how to make the "date" command give you the output format you want. At least not directly. A clever user might extrapolate from the "ls -l" and "alias" examples that they could create an alias for "date" which would pass a customized + argument for a customized output format. And that's certainly possible, but isn't something I'd choose to do. Most importantly because it would only affect the "date" command typed in an interactive shell; it wouldn't affect date(1) run by scripts, or anything else which uses the %c format operator in strftime(3). If you want to get rid of the 12-hour time format by *default* (%c), then neither of these chapters actually helps you. What you want to do is override the LC_TIME variable. unicorn:~$ (unset LC_TIME; date) Mon Dec 4 01:32:29 PM EST 2023 unicorn:~$ LC_TIME=C date Mon Dec 4 13:32:33 EST 2023 On my system (Debian 12), the default LC_TIME format in the en_US.utf8 locale is that 12-hour thing. I have "export LC_TIME=C" in my shell's dot files, so that I get the traditional 24-hour output instead. This affects all uses of strftime's %c, including bash's builtin printf: unicorn:~$ printf '%(%c)T\n' Mon Dec 4 13:34:35 2023 unicorn:~$ LC_TIME=en_US.utf8 printf '%(%c)T\n' Mon 04 Dec 2023 01:34:42 PM EST Sadly, you're restricted to the choices offered by your installed locales. If you can't find an installed locale which has an acceptable LC_TIME format, then you can try to roll your own. I went down that road once. It didn't really work out for me. Too many finicky details that simply don't work out in reality. > I hope, no applications rely on specific locale while parsing time or > numbers. I would not care to wager on that. > echo "$TZ" This is almost always unset. Normal users don't tend to set this. It's just not part of the public consciousness, for whatever reason. The *vastly* overwhelming majority of users rely on their system's default time zone instead. > https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html > but ignore most of its content, use zone identifiers like America/New_York Or whatever is in your system's /usr/share/zoneinfo/ or wherever your system's /etc/localtime symlink points. WE ARE STILL WAITING TO SEE WHERE GENE'S /etc/localtime POINTS. Hint, hint.
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-16 11:40 +0100 |
| Message-ID | <HLAfo-dXcq-7@gated-at.bofh.it> |
| In reply to | #264236 |
On 05/12/2023 01:41, Greg Wooledge wrote: > unicorn:~$ LC_TIME=en_US.utf8 printf '%(%c)T\n' > Mon 04 Dec 2023 01:34:42 PM EST > > Sadly, you're restricted to the choices offered by your installed locales. > If you can't find an installed locale which has an acceptable LC_TIME > format, then you can try to roll your own. I went down that road once. > It didn't really work out for me. Too many finicky details that simply > don't work out in reality. I think, absence of really flexible time formats may be intentional. At first I was surprised that Intl.DateTimeFormat in JavaScript does not have a method similar to strftime. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat Perhaps I have noticed rationale reading docs related to the Temporal proposal. Time formats vary greatly across the world. So if a developer fix particular format using % specifiers then the format may be rather strange for users from other countries. It is safer to specify locale and some hints like long/short. In addition, Gregorian calendar is not the only option. Formats of dates and time are a part of Common Locale Data Repository https://cldr.unicode.org/
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2023-12-04 22:30 +0100 |
| Message-ID | <HHoFP-bb6O-3@gated-at.bofh.it> |
| In reply to | #264227 |
On 12/4/23 11:34, Greg Wooledge wrote: > On Mon, Dec 04, 2023 at 10:55:47AM -0500, gene heskett wrote: >> root@mkspi:/etc# chronyc sources >> 210 Number of sources = 1 >> MS Name/IP address Stratum Poll Reach LastRx Last sample >> >> =============================================================================== >> ^* coyote.coyote.den 2 6 17 42 -22us[ -25us] +/- >> 41ms > > I've never used chrony, but that looks good at first glance. > >> root@mkspi:/etc# date >> Mon 04 Dec 2023 07:34:59 AM PST >> its 10:35 here, still 3 hours off. > > The time is *correct*, it's just being reported for a different time > zone than you want. > >> So here on coyote: date -u: >> Mon Dec 4 15:47:44 UTC 2023 >> but on mkspi: date -u: >> Mon 04 Dec 2023 03:47:16 PM UTC > > Again, both correct. > >> WTH? Where is that false 12 hour offset coming from? > > There is no 12 hour offset. One is being reported in 24-hour time, and > the other in 12-hour time (it says "PM"), because of different locale > definitions. > > All you need to do is change your system's default time zone, which on > Debian involves changing the *file* /etc/timezone and the *symlink* > /etc/localtime. Both are required, because some programs use one and > some use the other. > > We've said this in like 3 other emails so far. True, but I don't recall /etc/localtime until today. I thank you again. > > . Cheers, Gene Heskett. -- "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]
| From | John Hasler <john@sugarbit.com> |
|---|---|
| Date | 2023-12-04 17:40 +0100 |
| Message-ID | <HHk9b-b7oo-9@gated-at.bofh.it> |
| In reply to | #264220 |
Gene writes:
> Thats says this machine has it hdware clock on utc.
No. That says that the system clock (not the hardware clock) is
synchronized to NTP time. The system clock keeps UNIX time: seconds
since the epoch. It is converted to either UTC or local time as
approporiate for display. It says nothing about the hardware clock.
Try
hwclock -l
to find out what timezone the hardwareclock is set to.
If the box is running systemd try
timedatectl
--
John Hasler
john@sugarbit.com
Elmwood, WI USA
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2023-12-04 22:40 +0100 |
| Message-ID | <HHoPv-bbeb-19@gated-at.bofh.it> |
| In reply to | #264228 |
On 12/4/23 11:39, John Hasler wrote: > Gene writes: >> Thats says this machine has it hdware clock on utc. > > No. That says that the system clock (not the hardware clock) is > synchronized to NTP time. The system clock keeps UNIX time: seconds > since the epoch. It is converted to either UTC or local time as > approporiate for display. It says nothing about the hardware clock. > > Try > > hwclock -l > > to find out what timezone the hardwareclock is set to. > > If the box is running systemd try > > timedatectl Its ( the printer ) is still buster, so that conversion is incomplete. Thanks John. > > Cheers, Gene Heskett. -- "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]
| From | Tom Furie <tom@furie.org.uk> |
|---|---|
| Date | 2023-12-04 17:50 +0100 |
| Message-ID | <HHkiS-b7tN-3@gated-at.bofh.it> |
| In reply to | #264220 |
gene heskett <gheskett@shentel.net> writes:
> Mon Dec 4 15:47:44 UTC 2023
> Mon 04 Dec 2023 03:47:16 PM UTC
> WTH? Where is that false 12 hour offset coming from?
There's no offset. 15:00 UTC *is* 03:00 PM UTC
^^
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-04 20:20 +0100 |
| Message-ID | <HHmE1-b9ua-11@gated-at.bofh.it> |
| In reply to | #264210 |
On Mon, Dec 04, 2023 at 02:11:51PM -0500, gene heskett wrote: > That leave the localtime error pretty much up to the date command, or is > there something else screwing with this? Where ALL in this chain does > /etc/timezone get used, which is currently set to: > America/New_York ls -ld /etc/*time* Please.
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | linux.debian.user
csiph-web