systemd Timer und Zeitumstellung

[Friedemann Stoyan]

Guten Morgen NG!

Ich habe einen systemd Timer, der läuft alle 5 Minuten und pollt per SNMP
verschiedene Geräte ab:

# /etc/systemd/system/observium-poller.timer
[Unit]
Description=Run observium poller every 5 minutes

[Timer]
Persistent=true
OnCalendar=*:0/5

[Install]
WantedBy=timers.target

Das klappt auch gut, bis heute Nacht. Da ist nämlich zwischen 2 und 3Uhr eine
Lücke. Die Stunde war ja auch doppelt. Da hat der Timer einfach nichts
gemacht. Bug oder Feature? Eventuell die Persistenz rausnehmen, damit der
Timer nicht mehr weiss, wann er gelaufen ist?


mfg Friedemann

[Marcel Mueller]

Am 29.10.23 um 05:37 schrieb Friedemann Stoyan:

> Ich habe einen systemd Timer, der läuft alle 5 Minuten und pollt per SNMP
> verschiedene Geräte ab:

> Das klappt auch gut, bis heute Nacht. Da ist nämlich zwischen 2 und 3Uhr eine
> Lücke. Die Stunde war ja auch doppelt. Da hat der Timer einfach nichts
> gemacht. Bug oder Feature? Eventuell die Persistenz rausnehmen, damit der
> Timer nicht mehr weiss, wann er gelaufen ist?

Auf was läuft denn deine Systemuhr? UTC oder local Time?

In ersterem Fall wäre es m.E. ein Bug. In letzterem wundert mich gar nichts.

Ein Zusammenhang mit Persistent würde mich auch nicht überraschen, zumal
das einigermaßen sinnlos ist, wenn ein Job alle 5 Minuten läuft, die
verpassten Läufe nachzuholen.


Marcel

[Stefan Reuther]

Am 29.10.2023 um 05:37 schrieb Friedemann Stoyan:
> [Timer]
> Persistent=true
> OnCalendar=*:0/5
[...]

> Das klappt auch gut, bis heute Nacht. Da ist nämlich zwischen 2 und 3Uhr eine
> Lücke. Die Stunde war ja auch doppelt. Da hat der Timer einfach nichts
> gemacht. Bug oder Feature? Eventuell die Persistenz rausnehmen, damit der
> Timer nicht mehr weiss, wann er gelaufen ist?

Disclaimer: systemd-Timer kenn ich nicht spezifisch, aber Timer-APIs.

`OnCalendar` ist dokumentiert als "schaut auf die Kalenderzeit"
("Defines realtime (i.e. wallclock) timers with calendar event
expressions."). Dann macht es auch alle Ferkeleien der Kalenderzeit mit.
In den APIs wäre das CLOCK_REALTIME.

Der Timer, der von solchen Sprüngen unbeeinflusst bleibt, wäre
CLOCK_MONOTONIC. Und da klingen, der Dokumentation nach, `OnStartupSec`
und Geschwister so als ob es das wäre, was du suchst ("These are
monotonic timers, independent of wall-clock time and timezones.").


Stefan

[Marcel Mueller]

Am 29.10.23 um 09:24 schrieb Stefan Reuther:

> Disclaimer: systemd-Timer kenn ich nicht spezifisch, aber Timer-APIs.
>
> `OnCalendar` ist dokumentiert als "schaut auf die Kalenderzeit"
> ("Defines realtime (i.e. wallclock) timers with calendar event
> expressions."). Dann macht es auch alle Ferkeleien der Kalenderzeit mit.
> In den APIs wäre das CLOCK_REALTIME.

Du hast natürlich recht. Auch wenn die Doku nicht explizit auf DST
eingeht, legt sowohl der Name als auch die Möglichkeit eine Zeitzone in
der Zeile mit anzugeben nahe, dass es sich per default um die lokale
Zeit handelt.

Damit ergeben sich zwei Lösungen für den OP:

1. Geeignete Zeitzone angeben:
OnCalendar=*:0/5 Etc/GMT
(UTC könnte evtl. schon wieder Heckmeck mit Schaltsekunden machen)

2. Wiederholintervall statt absolutem Zeitpunkt verwenden:
OnBootSec=300
OnUnitActiveSec=300
etc.

In letzterem Fall läuft der Job halt nicht immer genau zum
5-Minuten-Intervall, was bei längeren Zeitreihen lästig sein kann, wenn
man z.B. per Fouriertransformation nach Regelmäßigkeiten suchen will.


Marcel

[Peter J. Holzer]

On 2023-10-29 09:36, Marcel Mueller <news.5...@spamgourmet.org> wrote:
> Am 29.10.23 um 09:24 schrieb Stefan Reuther:
>> Disclaimer: systemd-Timer kenn ich nicht spezifisch, aber Timer-APIs.
>>
>> `OnCalendar` ist dokumentiert als "schaut auf die Kalenderzeit"
>> ("Defines realtime (i.e. wallclock) timers with calendar event
>> expressions."). Dann macht es auch alle Ferkeleien der Kalenderzeit mit.
>> In den APIs wäre das CLOCK_REALTIME.
>
> Du hast natürlich recht. Auch wenn die Doku nicht explizit auf DST
> eingeht, legt sowohl der Name als auch die Möglichkeit eine Zeitzone in
> der Zeile mit anzugeben nahe, dass es sich per default um die lokale
> Zeit handelt.

Allerdings sollte IMHO auch in lokaler Zeit "in jeder durch 5 teilbaren
Minute" in der doppelten Stunde zutreffen.

Erst bei Zeitangaben, die auch die Stunde betreffen (z.B. "jeden Tag um
02:30") macht es Sinn, diese Stunden besonders zu berücksichtigen.

> 1. Geeignete Zeitzone angeben:
> OnCalendar=*:0/5 Etc/GMT
> (UTC könnte evtl. schon wieder Heckmeck mit Schaltsekunden machen)

Da alle Zeitzonen von UTC abgeleitet sind, hast allfälliges Heckmeck mit
Schaltsekunden auch dort.

hp

[Christian Garbs]

Mahlzeit!

Peter J. Holzer <hjp-u...@hjp.at> wrote:

>> 1. Geeignete Zeitzone angeben:
>> OnCalendar=*:0/5 Etc/GMT
>> (UTC könnte evtl. schon wieder Heckmeck mit Schaltsekunden machen)
>
> Da alle Zeitzonen von UTC abgeleitet sind, hast allfälliges Heckmeck mit
> Schaltsekunden auch dort.

Hat sich da was geändert?

Früher™ gab es Schaltsekundenunterschiede zwischen GMT und UTC, das
bilde ich mir zumindest ein.

Eine aktuelle Google-Suche liefert vieles in der Art von "UTC ist der
Standard. GMT die Zeitzone +00:00 darunter", effektiv sind beide
Zeiten wohl also gleich.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Ein Junggeselle ist ein Mann, dem zum Glück die Frau fehlt.

[Peter J. Holzer]

On 2023-10-29 13:01, Christian Garbs <mi...@cgarbs.de> wrote:
> Peter J. Holzer <hjp-u...@hjp.at> wrote:
>
>>> 1. Geeignete Zeitzone angeben:
>>> OnCalendar=*:0/5 Etc/GMT
>>> (UTC könnte evtl. schon wieder Heckmeck mit Schaltsekunden machen)
>>
>> Da alle Zeitzonen von UTC abgeleitet sind, hast allfälliges Heckmeck mit
>> Schaltsekunden auch dort.
>
> Hat sich da was geändert?
>
> Früher™ gab es Schaltsekundenunterschiede zwischen GMT und UTC, das
> bilde ich mir zumindest ein.

GMT kann je nach Kontext verschiedene Dinge bedeuten. In der Navigation
ist es laut Wikipedia ein Synonym für UT1 (das ist offenbar das, was Du
im Kopf hast), aber das hat für Linux (und andere Mainstream-OSs,
Internet-Protoklle, etc.) keine Bedeutung. Hier ist es ein Synonym für
UTC.

Dazu kommt in Linux ganz praktisch, dass die interne Repräsentation der
Zeit keinen Platz für Schaltsekunden lässt. Laut POSIX-Standard muss
sich der time_t-Wert jeden Tag um exakt 86400 erhöhen. Die traditionelle
Methode, damit umzugehen, war, die Zeit am Ende der Schaltsekunde
einfach hart um eine Sekunde zurückzustellen. Das ist für manche
Applikationen schlecht, weshalb in den letzten Jahren manche dazu
übergegangen sind, die Zeit über mehrere Stunden einzuschleifen. Dann
ist zwar die lokale Zeit zwischen T-h und T+h falsch (um bis zu 0.5
Sekunden), aber das ist weniger störend als ein falscher Sprung, vor
allem, wenn alle Rechner die gleiche falsche Zeit haben).

hp

[Friedemann Stoyan]

Marcel Mueller wrote:

> Damit ergeben sich zwei Lösungen für den OP:

> 1. Geeignete Zeitzone angeben:
> OnCalendar=*:0/5 Etc/GMT
> (UTC könnte evtl. schon wieder Heckmeck mit Schaltsekunden machen)

> 2. Wiederholintervall statt absolutem Zeitpunkt verwenden:
> OnBootSec=300
> OnUnitActiveSec=300
> etc.

Das sieht ja sehr zielführend aus. Ich werde das mal umstricken. Leider muß ich
jetzt ein Jahr warten, bevor ich den Effekt sehen kann.


mfg Friedemann

[Kay Martinen]

Am 29.10.23 um 16:19 schrieb Friedemann Stoyan:

Dann bedenke gleich den Fall der fehlenden Stunde im Frühjahr wenn um 2
Uhr nahtlos auf 3 Gesprungen wird.

Das die Zeitumstellung bis dahin Geschichte ist glaubt doch wohl keiner
mehr oder?

BTW. Im OP las ich was von observium. Das hatte ich hier in einem LXC
laufen aber nicht mehr bei der Umstellung heute. Das war aber ein OotB
Turnkey-System (via Proxmox) und da wäre ich mir nicht sicher ob solche
Änderungen update-fest wären. Ein Debian gibt einem ja zumindest noch
die Auswahl bei manuell geänderten configs aber bei systemd units weiß
ich das nicht. Wäre evtl. sinnvoll das mal zu überprüfen - nach einem
update. Und das ein neuerer systemd etwas anders versteht als sein
vorgänger soll doch auch schon vorgekommen sein wenn ich recht erinnere.

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

[Christian Garbs]

Mahlzeit!

Kay Martinen <use...@martinen.de> wrote:

> Ein Debian gibt einem ja zumindest noch die Auswahl bei manuell
> geänderten configs aber bei systemd units weiß ich das nicht.

Wenn Du Deine systemweiten systemd-Units als root mit "systemctl
--edit" bearbeitest, landen die Overrides unterhalb von /etc/systemd
und werden als conffiles behandelt.

Da die systemd-Overrides aber vollkommen unabhängig von Debian schon
für die Trennung zwischen den Einstellungen Deiner Distribution und
Deinen eigenen Änderungen sorgen (eigentlich ein total cooles
Feature), ist das in dem Fall ziemlich egal.

Problematisch wird es, wenn Deine Overrides im Falle eines Updates der
systemweiten Unit nicht mehr passend sind – den Fall hast Du aber
immer.

(Wobei man Ungereimtheiten bei einem Override vielleicht schlechter
bemerkt, als wenn Debian einen Konflikt in einem regulären conffile
beim Update meldet. Aber auf nicht Debian-Distributionen sind die
Overrides definitiv ein Fortschritt.)

Gru0
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Ich hätte gern einen kürzeren Brief geschrieben,
aber hatte dafür nicht die Zeit.

[Stefan Reuther]

Am 29.10.2023 um 12:31 schrieb Peter J. Holzer:
> On 2023-10-29 09:36, Marcel Mueller <news.5...@spamgourmet.org> wrote:
>> Am 29.10.23 um 09:24 schrieb Stefan Reuther:
>>> Disclaimer: systemd-Timer kenn ich nicht spezifisch, aber Timer-APIs.
>>>
>>> `OnCalendar` ist dokumentiert als "schaut auf die Kalenderzeit"
>>> ("Defines realtime (i.e. wallclock) timers with calendar event
>>> expressions."). Dann macht es auch alle Ferkeleien der Kalenderzeit mit.
>>> In den APIs wäre das CLOCK_REALTIME.
>>
>> Du hast natürlich recht. Auch wenn die Doku nicht explizit auf DST
>> eingeht, legt sowohl der Name als auch die Möglichkeit eine Zeitzone in
>> der Zeile mit anzugeben nahe, dass es sich per default um die lokale
>> Zeit handelt.
>
> Allerdings sollte IMHO auch in lokaler Zeit "in jeder durch 5 teilbaren
> Minute" in der doppelten Stunde zutreffen.

Das wäre halt ein Spezialfall, der explizit zu erkennen ist ("es ist nur
eine Minute angegeben").

Dann gibt's bei CLOCK_REALTIME ja auch noch den nicht ganz
unwahrscheinlichen Fall, dass da einer mal dran rumdreht ("oh, Uhr geht
3 Minuten nach"), was macht man, wenn dadurch ein 5-Minuten-Intervall
übersprungen wird? CLOCK_MONOTONIC hat solche Probleme halt einfach
nicht, denn dafür wurde es eingeführt.


Stefan

[Marcel Mueller]

Am 29.10.23 um 12:31 schrieb Peter J. Holzer:

>> (UTC könnte evtl. schon wieder Heckmeck mit Schaltsekunden machen)
>
> Da alle Zeitzonen von UTC abgeleitet sind, hast allfälliges Heckmeck mit
> Schaltsekunden auch dort.

Mir war, dass Greenwich _Mean_ Time genau das nicht hat, und dass darin
die Sekunden ggf. etwas gestreckt oder gestaucht werden, damit genau das
nicht passiert. Jedenfalls dürfte die wenigsten Parser 23:59:60 akzeptieren.


Marcel

[Peter J. Holzer]

On 2023-10-30 18:13, Marcel Mueller <news.5...@spamgourmet.org> wrote:
> Am 29.10.23 um 12:31 schrieb Peter J. Holzer:
>>> (UTC könnte evtl. schon wieder Heckmeck mit Schaltsekunden machen)
>>
>> Da alle Zeitzonen von UTC abgeleitet sind, hast allfälliges Heckmeck mit
>> Schaltsekunden auch dort.
>
> Mir war, dass Greenwich _Mean_ Time genau das nicht hat,

Wie bereits geschrieben, hat "Greenwich Mean Time" mehrere Bedeutungen.

(Ich hatte hier bereits bereits zwei Absätze über die Geschichte
geschrieben, aber da ich die Details nicht auswendig weiß und in der
Wikipedia nachschlagen muss, habe ich die wieder gelöscht - kann ja
jeder auch selber nachlesen.)

Solange man nicht spezifiziert, was man mit "GMT" eigentlich meint, kann
man nicht sagen, ob es Schaltsekunden gibt oder nicht.

In manchem technisch-wissenschaftlichem Kontext ist GMT eine alternative
Bezeichnung für UT1. Das beruht auf der (geglätteten) Erdrotation und
hat keine Schaltsekunden.

Das ist aber nicht das, was die Öffentlichkeit unter GMT versteht und
ganz sicher nicht das, was Du bekommst, wenn Du auf einem Computer "GMT"
als Zeitzone einstellst. Das ist *zivile* Zeit und die beruht weltweit
auf UTC. Somit gibt es hier Schaltsekunden, auch wenn die meistens nicht
korrekt implementiert werden.

> und dass darin die Sekunden ggf. etwas gestreckt oder gestaucht
> werden, damit genau das nicht passiert. Jedenfalls dürfte die
> wenigsten Parser 23:59:60 akzeptieren.

Das ist wieder etwas anderes.

Auf POSIX-kompatiblen Betriebssystemen ist 23:59:60 nicht abbildbar.
2016-12-31T23:59:59Z war 1483228799 und 2017-01-01T00:00:00Z war
1483228800. Dazwischen ist kein Platz für eine weitere Sekunde. Das mag
man den Erfindern von Unix anlasten, die Mitte der 1970er-Jahre nicht
bemerkt haben, dass jedes Jahr eine Sekunde zu lang war (oder das für
vernachlässigbar hielten) oder den Machern von POSIX, die das 1988 nicht
korrigierten (aber da gab es halt schon ziemlich viele Unix-Systeme),
aber jedenfalls kann man das nicht mehr ändern.

Also gibt es drei Möglichkeiten:

1) Man ignoriert das Problem. Dann stellt man bei der ersten
Zeitsynchronisation nach der Schaltsekunde fest, dass die Uhr eine
Sekunde vorgeht und stellt sie zurück. Entweder sprunghaft oder
kontinuierlich über einen längeren Zeitraum. Vorteil: Einfach.
Nachteil: In einem Netzwerk wird jeder Computer zu einem anderen
Zeitpunkt feststellen, dass die Uhr falsch geht und man hat dann ein
paar Minuten bis ein paar Stunden lang ein bisschen ein Chaos.
Außerdem kann der plötzliche große Fehler von einer Sekunde zu
Überschwingen führen (je nach Algorithmus).

2) Man stellt exakt um Mitternacht UTC die Zeit auf 23:59:59 zurück.
Diese Sekunde ist dann doppelt. Das war klassischerweise das, was
NTP-Implementationen gemacht haben (NTP setzt rechtzeitig vorher ein
NTP-Flag, damit die Clients diesen Sprung exakt timen können).
Vorteil: Die Zeit ist bis 23:59:59 korrekt und ab 00:00:00 wieder.
Man hat nur 2 Sekunden Chaos, aber da geballt, da viele Programme
mit einem Rückwärtssprung in der Zeit nicht zurechtkommen.

3) Man "verschmiert" die Schaltsekunde. 12 Stunden vorher macht man die
Uhr um 1/86400 langsamer, 12 Stunden nachher schaltet man wieder auf
normale Geschwindigkeit. Damit hat vor 10 Jahren oder so Google
angefangen, und seitdem haben das etliche übernommen. Vorteil: Es
gibt keinen Zeitsprung, und weil alle Computer (die dieses Verfahren
einsetzen) synchron falsch gehen, gibt es auch keine Diskrepanzen
zwischen den Computern. Nachteil: Alle Computer gehen 24 h rund um
die Schaltsekunde um bis zu einer halben Sekunde falsch (zuerst
nach, dann vor) und außerdem zu langsam.

Das sind aber Strategien, um "POSIX-Zeit" an UTC anzupassen. Mit GMT hat
das alles nichts zu tun.

hp

[Clemens Schüller]

Servus!

Andreas Kohlbach schrieb am 30. Oct. 2023 um 23:51:


> leafonde nahm ich in Europa wegen Dial-Up. Seitdem sich DSL oder Kabel
> durchsetzte, ziehe ich News aber direkt vom Server: man ist ja immer
> online. Ich erinnerte mich bei diesem Thema nur gerade daran.

Leafnode habe ich in Zeiten von 56k verwendet - war erinnerlich von 1999
bis 2002. Erst dann hab ich endlich einen DSL Link bekommen.

War im ländlichen Dorf - lang, lang ist es her :-D


--
LieGrü aus Graz, Clemens

[Helmut Waitzmann]

"Peter J. Holzer" <hjp-u...@hjp.at>:

Beispielsweise „make“, das sich darauf verlässt, dass die Uhr nie
rückwärts geht, ist so ein Programm.

> 3) Man "verschmiert" die Schaltsekunde. 12 Stunden vorher macht man die
> Uhr um 1/86400 langsamer, 12 Stunden nachher schaltet man wieder auf
> normale Geschwindigkeit. Damit hat vor 10 Jahren oder so Google
> angefangen, und seitdem haben das etliche übernommen. Vorteil: Es
> gibt keinen Zeitsprung, und weil alle Computer (die dieses Verfahren
> einsetzen) synchron falsch gehen, gibt es auch keine Diskrepanzen
> zwischen den Computern. Nachteil: Alle Computer gehen 24 h rund um
> die Schaltsekunde um bis zu einer halben Sekunde falsch (zuerst
> nach, dann vor) und außerdem zu langsam.
>

Mit glibc gibt es noch eine Möglichkeit, die nicht zu POSIX
kompatibel ist:


Man lässt die Maschine Schaltsekunden mitzählen, das heißt, im
Fall einer Schaltsekunde hält man den Sekundenzähler, der die
Sekunden seit 1970-01-01T00:00:00Z zählt, weder für eine Sekunde
an, noch stellt man ihn eine Sekunde zurück, noch lässt man ihn
in der Umgebung der Schaltsekunde langsamer laufen, sodass also
jede Schaltsekunde seit 1970-01-01T00:00:00Z den Sekundenzähler
eine Sekunde weiterzählen lässt.


Dadurch, dass der Sekundenzähler stur durchläuft, hält er mit dem
Sekundenzähler der internationalen Atomzeit (TAI,
<https://de.wikipedia.org/wiki/Internationale_Atomzeit#top>)
Schritt, d. h. er bleibt über die Schaltsekunden hinweg in
konstantem Abstand zur TAI.  Weil inzwischen 37 Schaltsekunden
aufgelaufen sind, der Zähler also seit 1970-01-01T00:00:00Z 37
Mal angehalten worden war, stellt man ihn (also die Systemuhr)
derzeit einmalig um 37 Sekunden voran, damit er auf die TAI kommt
(und zukünftig bei ihr bleibt).


Dann teilt man glibc (und damit auch dem Programm „date“) mittels
der Umgebungsvariablen „TZDIR“ und „TZ“ und/oder der Datei
„localtime“ mit, die Variante der Zeitzonendatenbank, die
Schaltsekunden enthält, zu verwenden.  (Würde man das nicht tun,
bekäme man die TAI anstelle der UTC angezeigt.)


Beispielsweise sind mit dem Shell‐Kommando (mit GNU‐date)


(
for schaltsekunde in \
'1972-06-30 23:59:60' \
'1972-12-31 23:59:60'
do
echo
for umgebung in 'now -1 seconds' '' 'now +1 seconds'
do
printf 'TZ=":Etc/UTC" %s %s\n' "$schaltsekunde" "$umgebung"
done |
TZDIR=/usr/share/zoneinfo/right/ TZ=:Etc/UTC \
date -f - -- \
'+%Y-%m-%dT%TZ = %s Sekunden seit 1970-01-01T00:00:00Z'
done
)


die erste und die zweite Schaltsekunde mit jeweils der Sekunde
davor und der danach zu sehen:



1972-06-30T23:59:59Z = 78796799 Sekunden seit 1970-01-01T00:00:00Z
1972-06-30T23:59:60Z = 78796800 Sekunden seit 1970-01-01T00:00:00Z
1972-07-01T00:00:00Z = 78796801 Sekunden seit 1970-01-01T00:00:00Z

1972-12-31T23:59:59Z = 94694400 Sekunden seit 1970-01-01T00:00:00Z
1972-12-31T23:59:60Z = 94694401 Sekunden seit 1970-01-01T00:00:00Z
1973-01-01T00:00:00Z = 94694402 Sekunden seit 1970-01-01T00:00:00Z


Das hat den Vorteil, dass die Uhr bei Schaltsekunden nicht
nachgeführt werden muss, sondern unbehelligt weiterlaufen kann: 
Sie macht keine Pausen und keine Sprünge, jede Sekunde ist gleich
lang, und auch die Schaltsekunden, die ja tatsächlich auftreten
(wie man mit jeder Stoppuhr im Beobachten einer DCF77‐Funkuhr
nachprüfen kann), haben ihre Entsprechung im Sekundenzähler.


Nochmal zitiert:

> Auf POSIX-kompatiblen Betriebssystemen ist 23:59:60 nicht
> abbildbar. 2016-12-31T23:59:59Z war 1483228799 und
> 2017-01-01T00:00:00Z war 1483228800. Dazwischen ist kein Platz
> für eine weitere Sekunde.
>

Mit der geschilderten Abweichung von POSIX ist dann auch
1972-06-30T23:59:60Z eine gültige Zeitangabe, denn sie hat ihren
Platz im Sekundenzähler.