chronyd synct nicht bei Laptop-Start

[dirk11]

Ich danke euch für eure Unterstützung!

Ich wollte das Problem eigentlich schon als "gelöst" setzen und als letztes Posting eine Zusammenfassung schreiben, stelle aber zu Hause fest, dass es an Laptop #2 nicht funktioniert hat:
Gerät steckt in Docking-Station und ist per LAN angebunden.
Verzeichnis und Datei erstellt, Inhalt reinkopiert, Rechner neu gestartet. Keine Auswirkung. Mit sysctl alles kontrolliert, ist exakt so wie auf dem anderen Rechner. Nochmal rebootet, wieder keine Auswirkung.
Also mal aus der Docking-Station genommen und neu gestartet, so dass er nur Verbindung zum WLAN hat. Seitdem geht es, auch wenn der Gerät in der Docking station steckt.
Ein sehr merkwürdiges Problem.

[mat6937]

... es an Laptop #2 nicht funktioniert hat:
Gerät steckt in Docking-Station und ist per LAN angebunden.
Verzeichnis und Datei erstellt, Inhalt reinkopiert, Rechner neu gestartet. Keine Auswirkung. ...
Ein sehr merkwürdiges Problem.

Auch dafür muss es eine Lösung geben.
Poste mal die Ausgabe von:

Code: Alles auswählen

systemctl cat NetworkManager-wait-online.service

Edit:

... und von diesem Laptop #2, die Ausgabe von:

Code: Alles auswählen

ip link

EDIT 2:

... so dass er nur Verbindung zum WLAN hat. Seitdem geht es, auch wenn der Gerät in der Docking station steckt.

Wenn das Gerät (Laptop #2) _jetzt_ (wenn es funktioniert) in der Docking station steckt, ist der Laptop #2 dann per Lan oder per Wlan mit dem Router verbunden?

[dirk11]

Auch dafür muss es eine Lösung geben.
Poste mal die Ausgabe von:

Code: Alles auswählen

systemctl cat NetworkManager-wait-online.service

Edit:
... und von diesem Laptop #2, die Ausgabe von:

Code: Alles auswählen

ip link

EDIT 2:

... so dass er nur Verbindung zum WLAN hat. Seitdem geht es, auch wenn der Gerät in der Docking station steckt.

Wenn das Gerät (Laptop #2) _jetzt_ (wenn es funktioniert) in der Docking station steckt, ist der Laptop #2 dann per Lan oder per Wlan mit dem Router verbunden?

Ich denke nicht, dass wir da herausfinden, woran das lag, denn jetzt funktioniert es immer, egal ob es in der Docking-station steckt oder nicht, egal ob es ausgeschaltet war oder "nur" rebootet wurde.
Wenn es in der DS steckt, hat die eth-Verbindung Priorität.
Gerne dennoch die Ausgaben:

Code: Alles auswählen

$ systemctl cat NetworkManager-wait-online.service
# /lib/systemd/system/NetworkManager-wait-online.service
[Unit]
Description=Network Manager Wait Online
Documentation=man:nm-online(1)
Requires=NetworkManager.service
After=NetworkManager.service
Before=network-online.target

[Service]
# `nm-online -s` waits until the point when NetworkManager logs
# "startup complete". That is when startup actions are settled and
# devices and profiles reached a conclusive activated or deactivated
# state. It depends on which profiles are configured to autoconnect and
# also depends on profile settings like ipv4.may-fail/ipv6.may-fail,
# which affect when a profile is considered fully activated.
# Check NetworkManager logs to find out why wait-online takes a certain
# time.

Type=oneshot
ExecStart=/usr/bin/nm-online -s -q
RemainAfterExit=yes

# Set $NM_ONLINE_TIMEOUT variable for timeout in seconds.
# Edit with `systemctl edit NetworkManager-wait-online`.
#
# Note, this timeout should commonly not be reached. If your boot
# gets delayed too long, then the solution is usually not to decrease
# the timeout, but to fix your setup so that the connected state
# gets reached earlier.
Environment=NM_ONLINE_TIMEOUT=60

[Install]
WantedBy=network-online.target

Code: Alles auswählen

$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether b0:99:28:c6:ff:ff brd ff:ff:ff:ff:ff:ff
    altname enp0s25
3: wwan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether b6:36:66:32:ff:ff brd ff:ff:ff:ff:ff:ff
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
    link/ether a0:88:b4:db:ff:ff brd ff:ff:ff:ff:ff:ff
    altname wlp10s0

[mat6937]

Ich denke nicht, dass wir da herausfinden, woran das lag, denn jetzt funktioniert es immer, egal ob es in der Docking-station steckt oder nicht, egal ob es ausgeschaltet war oder "nur" rebootet wurde.
Wenn es in der DS steckt, hat die eth-Verbindung Priorität.

Ok, aber Du könntest evtl. trotzdem mit folgenden Ergänzungen nur auf dem Laptop #2 testen:

Ergänze in der Datei "/etc/systemd/system/chrony.service.d/addtarget.conf" die [Unit]-Section mit den Zeilen:

Code: Alles auswählen

Requires=sys-subsystem-net-devices-eth0.device
After=sys-subsystem-net-devices-eth0.device

danach rebooten und testen.
Wenn es Probleme gibt, kannst Du diese Ergänzungen kommentieren (#), so dass sie nicht mehr wirksam sind.

[dirk11]

Was bewirken denn die zwei Zeilen?

[mat6937]

Was bewirken denn die zwei Zeilen?

Mit chrony.service muss auch sys-subsystem-net-devices-eth0.device gestartet werden können bzw. schon gestartet sein. Wenn das nicht möglich ist, wird chrony.service nicht ausgeführt werden können, was dann sofort erkennbar ist bzw. auffällt.

[dirk11]

Ok, danke. Das Problem ist noch einmal aufgetreten, ich weiß aber nicht mehr, ob vor oder nach Einfügung dieser Zeilen. Es war auch für mich nicht reproduzierbar, ich habe nichts erkannt, wo ich hätte sagen können "bei diesen Konditionen tritt es auf". Ist vielleicht auch so ein Soda-Problem, welches einfach so da ist. An meinem Desktop passiert es manchmal beim Reboot, dass das nach die NIC nicht aktiv ist. Auch nicht herausfindbar, woran das liegt...

[mat6937]

Ist vielleicht auch so ein Soda-Problem, welches einfach so da ist.

Eigentlich sollte so etwas mit systemd nicht passieren, denn in einer service-unit kann man ganz genaue Abhängigkeiten eintragen/konfigurieren.
Was Du noch probieren kannst ist, die deaktivierte service-unit für chrony (chrony.service) mit Hilfe einer timer-unit (chrony.timer), z. B. 20 Sekunden nach aktiv werden dieser timer-unit zu starten. Zu diesem Zeitpunkt sollte immer Internetzugang (d. h. die Erreichbarkeit der Zeitserver) vorhanden sein:

Code: Alles auswählen

systemctl disable chrony.service

Code: Alles auswählen

nano /etc/systemd/system/chrony.timer

Inhalt:

Code: Alles auswählen

[Unit]
Description=start chrony-service

[Timer]
OnActiveSec=20

[Install]
WantedBy=multi-user.target timers.target

nach dem speichern:

Code: Alles auswählen

systemctl daemon-reload
systemctl enable chrony.timer

und rebooten.

[dirk11]

Mhmm. Die kann ich einfach mal hinzufügen. Ich meine mich aber zu erinnern, dass chronyd lief. Der hatte nur wieder bei chronyc acitivity alle Quellen auf "0" stehen.
Wäre da ein restart nicht sinnvoller? Das habe ich bisher auch gemacht, wenn bei activity nichts kam, habe ich chrony restartet, danach hat er sofort seine Quellen gefunden.
Wie würde das dafür aussehen?

Und noch eine Frage: da ich doch sowieso reboote, wozu muss ich dann noch systemctl daemon-reload machen?

[mat6937]

Ich meine mich aber zu erinnern, dass chronyd lief. Der hatte nur wieder bei chronyc acitivity alle Quellen auf "0" stehen.

Ja, laufen tut der schon, aber er konnte zum Zeitpunkt seines Starts keine Zeitserver erreichen, und deshalb ist es gut, dass er mit der timer-unit etwas später gestartet wird.

Wäre da ein restart nicht sinnvoller?

Ein restart ist weniger professionell als ein verzögerter Start via timer-unit. Für den restart braucht man dann ein Script, das per cronjob oder auch per timer-unit ausgeführt wird.

Und noch eine Frage: da ich doch sowieso reboote, wozu muss ich dann noch systemctl daemon-reload machen?

Nein, dann nicht, ... aber es schadet auch nicht wenn man es trotzdem macht.

[MSfree]

Ein restart ist weniger professionell als ein verzögerter Start via timer-unit.

Ein verzögerter Start über einen Zeitmechanismus ist ebenfalls Pfusch. Ideal ist, den Start von Bedigungen abhängig zu machen. Systemd weiß z.B. sehr genau, wann und ob das Netzwerk und somit ein NTP-Server erreichbar ist und kann chronyd abhängig davon zum genau richtigen Zeitpunkt starten.

[mat6937]

Ideal ist, den Start von Bedigungen abhängig zu machen.

Ja, ... Du darfst dich hier auch einbringen und dem TE, die für seinen Fall/Konstellation bzw. für sein System erforderlichen Bedingungen bzw. Abhängigkeiten vorschlagen/mitteilen.

[MSfree]

Ja, ... Du darfst dich hier auch einbringen und dem TE, die für seinen Fall/Konstellation bzw. für sein System erforderlichen Bedingungen bzw. Abhängigkeiten vorschlagen/mitteilen.

Keine Lust mich zu wiederholen. siehe 7. Beitrag in diesem Thread.

[dirk11]

Code: Alles auswählen

[Unit]
...
After=Network.target
...
[Service]
...
[Install]
WantedBy=nulti-user.target

sollte eigentlich reichen, damit der Prozeß es nach Etablierung des Netzwerks startet.

Und wo genau gehört das hin?

[mat6937]

Code: Alles auswählen

[Unit]
...
After=Network.target
...
[Service]
...
[Install]
WantedBy=nulti-user.target

sollte eigentlich reichen, damit der Prozeß es nach Etablierung des Netzwerks startet.

Und wo genau gehört das hin?

Nirgends, ... er meint network.target in die [Unit]-Section, denn:

Code: Alles auswählen

:~ $ systemctl status Network.target
Unit Network.target could not be found.

Entferne/kommentiere vorher die anderen hinzugefügten Abhängigkeiten.

[dirk11]

Leute, ernsthaft: das verwirrt mich ein kleines Bißchen - nicht weil ich vollkommen ahnungslos bin (Debian seit 2001), sondern weil ich in systemd noch nicht so fit bin.

Also: ich soll die vorher in /etc/systemd/system/chrony.service.d/addtarget.conf erstellten Zeilen auskommentieren und dann dort die paar Zeilen von @MSfree einfügen? Ab dem nächsten reboot sollte es dann damit funktionieren? Egal ob das device wlan0, eth0, ethX oder wlanX heißt, also universal?
Sprich alles bleibt wie bisher, nur die Einträge in die addtarget.conf für chrony ändern sich?

Kann mir bitte einer erläutern, was die einzelnen von @MSfree genannten Einträge genau bewirken (und was sie anderes bewirken als die Einträge von @mat6937), damit ich sie verstehe und das gelernte Wissen dann auf andere Situationen adaptieren kann?

[MSfree]

Nirgends, ... er meint network.target in die [Unit]-Section, denn:

Das gehört natürlich in die chrony.service.
Daß Network.target nicht gefunden wurde, liegt daran, daß ich das versehentlich mit großen "N" geschrieben habe. Noch besser wäre aber network-online.target.

[dirk11]

Also: After=network.target steht per default sowieso drin. Also geht es nur um den [Install]-Bereich? Und wieso gehört das jetzt in die chrony.service, ich denke, die ändert man nicht, sondern fügt das über die addtarget.conf für die chrony.service hinzu? Oder meinst Du das, hast Dich aber nur unpräzise ausgedrückt?

[mat6937]

Also: After=network.target steht per default sowieso drin. Also geht es nur um den [Install]-Bereich? Und wieso gehört das jetzt in die chrony.service, ich denke, die ändert man nicht, sondern fügt das über die addtarget.conf für die chrony.service hinzu? Oder meinst Du das, hast Dich aber nur unpräzise ausgedrückt?

Nein, so wie es jetzt ist, ist es ok bzw. Du hast alles richtig gemacht:
Dein Beitrag hier im Thread, vom: 25.01.2024 11:15:57 Uhr:

Code: Alles auswählen

# systemctl cat chrony
# /lib/systemd/system/chrony.service
[Unit]
Description=chrony, an NTP client/server
Documentation=man:chronyd(8) man:chronyc(1) man:chrony.conf(5)
Conflicts=openntpd.service ntp.service ntpsec.service
Wants=time-sync.target
Before=time-sync.target
After=network.target
ConditionCapability=CAP_SYS_TIME

[Service]
Type=forking
PIDFile=/run/chrony/chronyd.pid
EnvironmentFile=-/etc/default/chrony
User=_chrony
# Daemon is started as root, but still sandboxed
ExecStart=!/usr/sbin/chronyd $DAEMON_OPTS

CapabilityBoundingSet=~CAP_AUDIT_CONTROL CAP_AUDIT_READ CAP_AUDIT_WRITE
CapabilityBoundingSet=~CAP_BLOCK_SUSPEND CAP_KILL CAP_LEASE CAP_LINUX_IMMUTABLE
CapabilityBoundingSet=~CAP_MAC_ADMIN CAP_MAC_OVERRIDE CAP_MKNOD CAP_SYS_ADMIN
CapabilityBoundingSet=~CAP_SYS_BOOT CAP_SYS_CHROOT CAP_SYS_MODULE CAP_SYS_PACCT
CapabilityBoundingSet=~CAP_SYS_PTRACE CAP_SYS_RAWIO CAP_SYS_TTY_CONFIG CAP_WAKE_ALARM
DeviceAllow=char-pps rw
DeviceAllow=char-ptp rw
DeviceAllow=char-rtc rw
DevicePolicy=closed
LockPersonality=yes
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
PrivateTmp=yes
ProcSubset=pid
ProtectControlGroups=yes
ProtectHome=yes
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectProc=invisible
ProtectSystem=strict
# Used for gps refclocks
ReadWritePaths=/run
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
RestrictNamespaces=yes
RestrictSUIDSGID=yes
SystemCallArchitectures=native
SystemCallFilter=~@cpu-emulation @debug @module @mount @obsolete @raw-io @reboot @swap

ConfigurationDirectory=chrony
RuntimeDirectory=chrony
RuntimeDirectoryMode=0700
# See dumpdir in chrony.conf(5)
RuntimeDirectoryPreserve=restart
StateDirectory=chrony
StateDirectoryMode=0750
LogsDirectory=chrony
LogsDirectoryMode=0750

# Adjust restrictions for /usr/sbin/sendmail (mailonchange directive)
NoNewPrivileges=no
ReadWritePaths=-/var/spool
RestrictAddressFamilies=AF_NETLINK

[Install]
Alias=chronyd.service
WantedBy=multi-user.target

# /etc/systemd/system/chrony.service.d/addtarget.conf
[Unit]
After=network-online.target

chrony wird auf zwei deiner drei Systeme (Laptops) ja auch richtig gestartet bzw. synct auch beim start. Es geht um den Laptop #2. Wenn Du das mit der timer-unit (auch temporär) nicht probieren willst, dann lass es so wie es jetzt ist.

[dirk11]

Fein. Dann lass' ich es so. Ich kann es, wie gesagt, nicht reproduzieren. Das Problem ist 2x aufgetreten bei vielleicht 10 Starts/Reboots in der Zeit, seitdem Du mir die erste Lösung aufgezeigt hast. Von daher: weiß der Teufel. Der LAN-Anschluss steckt auch in der Docking-station, nicht direkt im Laptop. Vielleicht spielt auch das dabei eine Rolle. Solange es ansonsten tut, lasse ich das erstmal als Kuriosität stehen.

[cosinus]

Ich finde es schon ein wenig erstaunlich, dass hier über drei Seiten ne Diskussion entsteht, über einen Stanarddienstm der seit vielen Jahren problemfrei läuft.

[dirk11]

über einen Stanarddienstm der seit vielen Jahren problemfrei läuft.

Und ich finde es erstaunlich, dass Du es schaffst, die genannten vorhandenen Probleme einfach zu ignorieren. Aber wirklich super, dass Du Dich wieder an der Unterhaltung beteiligst, nachdem Du nichts zur Lösung beigetragen hast, außer wie Sauerbier anzubieten, die Software auszutauschen.

[mat6937]

..., lasse ich das erstmal als Kuriosität stehen.

OK. Wenn es wieder passieren sollte, dann poste die vollständigen Ausgaben von:

Code: Alles auswählen

cat /var/log/boot.log
systemd-analyze blame

und dann bei einem anderen Boot-Vorgang bei dem es nicht passiert, auch diese Ausgaben. Evtl. kann man in diesen Ausgaben einen (relevanten) Unterschied erkennen.

[cosinus]

Aber wirklich super, dass Du Dich wieder an der Unterhaltung beteiligst, nachdem Du nichts zur Lösung beigetragen hast, außer wie Sauerbier anzubieten, die Software auszutauschen.

Ob bitte 1000x Entschuldigung, dass ich eine funktionierende Alternative genannt habe!
Ich stell mich jetzt für ne halbe Stunde in die Ecke und schäme mich jetzt so richtig mal

[dirk11]

Du hast es geschafft. Ich kann Narzissten nicht leiden, schon gar nicht, wenn sie per PN so tun, als würden sie sich entschuldigen, und in der Öffentlichkeit alles in's Lächerliche ziehen. Versuchst erst, alle auf Dein Niveau herunter zu ziehen, und schlägst uns dann mit Erfahrung. Danke, aber nein Danke. Du bist seit Jahrzehnten der erste, der es in einem Forum auf meine Ignore-Liste schafft.