Auch wir verwenden hier Arch, wegen der "Ursprünglichkeit".
Was wir aber hassen, ist die Arroganz der Systemd Protagonisten, erstmal alle Fehler beim Anwender/Admin zu suchen.
Was uns hier am meisten geärgert hat: - defekte mount einbindung aus der fstab -- /home ist via NFS gemounted, -- /home/$user/[.local|.cache] sind btrfs subvols um dein DDOS gegen den NFS Server zu vermeiden, sonst liegt bei Arbeitsbegin, wenn die User hochfahren und einloggen der NFS server in der Ecke ...
Hier zeigen sich fatale Fehler: 1. /home mounted nicht, weil netwok.target falsch "online" meldet 2. obwohl /home nicht gemountet ist, werden fröhlich die /home/$user/.local mount eingehängt ...
- systemd-networkd-wait-online ist schlicht defekt: -- unzuverlässige Netzwerk Aktivierung beim Booten -- False Positive "Network up/Online" detection -- defekte Link Detection spziell wenn Bridged/Bonded devices im Spiel sind
Von network.target, systemd-networkd und systemd-networkd-wait-online abhängige units knallen dann total.
Bug gemeldet, und von Poettering ignoriert ... seit 2! Jahren offen
Von Verfluchtnochmal-05995bd7b am Fr, 26. Oktober 2018 um 23:50 #
> /home mounted nicht, weil netwok.target falsch "online" meldet
Vielleicht mal versuchen den Unterschied zwischen "network-online.target" und "netwok.target" verstehen dann wird es einfacher!
Mein "network-wan.service" der für eine DHCP-Adresse und Bridges sorgt hat "WantedBy=network.target", ist also Teil des "network.target" und wenn das und alles andere in "network.target" fertig ist kommt "network-online.target" zum Tragen
Und ja das macht Sinn und Nein mit sysvinitscripts war das nicht besser sondern nur scheisse langsam und im worst case ist der komplette Bootvorgang hängen geblieben
Von Verfluchtnochmal-05995bd7b am Sa, 27. Oktober 2018 um 15:33 #
Und zu
> obwohl /home nicht gemountet ist, werden fröhlich die /home/$user/.local mount eingehängt
Einfach mal die Dokus lesen, Condition* funktiniert fehlerfrei, seit Jahren, wenn es komplexer wird ist /etc/fstab schlichtweg das falsche Tool, dafür gibt es mount-units in denen du DInge ausdrücken kannst die die fstab im Traum nicht hergibt
Euer Hauptproblem scheint zu sein dass ihr euch eben nicht wirklich eingearbeitet habt und gerne alles wie früher hättet, wenn man mal wirklich die Konzepte hinter systemd verstanden hat ist das wesentlich einfacher zu handhaben als das Geschiss von Shellscripts die alle ihre eigene Semantik haben und voller Workarounds sind die sich auch noch zwicshen Distributionen unterscheiden
EDIT: Hab den Bugreport selbst gefunden und wie vermutet sind nahezu alle von dir gemeldeten Probleme auf zwei Ursachen zurück zu führen. Erstens werden Abhängigkeiten unzureichend oder sogar falsch definiert was bei einem parallelen boot wie systemd ihn verwendet nicht funktionieren kann. Und zum zweiten ist deine mount-Konfiguration so komplex das die fstab bei einem parallelen boot schlicht der falsche Platz ist um so etwas zu konfigurieren.
EDIT2: Das erste was du in den Griff bekommen müsstest wäre das was du in network.target und network-online.target "installiert" hast. Bei meinen Client-Rechnern ist es (in beiden Traget's) der NetworkManager und bei den Servern systemd-networkd. Und eigentlich funktionieren beide einwandfrei so lange ihnen kein anderes Tool (wie zum Beispiel eben libvirt) dazwischen funkt. Es gibt im Internet etliche Anleitungen darüber wie man systemd-networkd und libvirt fehlerfrei kombiniert und es wäre wohl nicht verkehrt sich die mal anzusehen.
Das zweite sind die etlichen in einander verschachtelten Einträge aus deiner fstab. Abgesehen von root, boot und swap müsste jeder Eintrag daraus in ein von dir erstelltes mount-Unit mit sauber definierten Abhängigkeiten (also mit korrekten "Requires" und "After" Optionen in der Unit-Sektion) umziehen. Der Generator den systemd für die Einträge aus der fstab-Datei anbietet ist nicht für ein so komplexes Gebilde wie das deine programmiert worden und sollte es auch nicht.
Bug gemeldet, und von Poettering ignoriert ... seit 2! Jahren offen
Ich kann ja deine Frustration zwar verstehen aber "ignoriert" hat dich niemand. So wie ich das sehe hat man trotz der Ausgangslage versucht dir zu helfen...
Dieser Beitrag wurde 6 mal editiert. Zuletzt am 29. Okt 2018 um 12:30.
Das sind die beiden Zeilen die deinem Service sagen "Du startest wenn das Netzwerk wirklich da ist", "Von network.target, systemd-networkd und systemd-networkd-wait-online abhängige units knallen dann total" ist damit reiner Bullshit weil du nicht von einzelnen Diensten abhängig bist sondern von Targets und da solltest du halt auch die richtigen benutzen
Und da sind wir wieder am Beginn: Basics verstehen dann klappt das auch weil "systemd-networkd-wait-online.service" ist ein SUBSET von "network-online.target"
Von Warum plötzlich so leise? am Di, 30. Oktober 2018 um 00:03 #
Erst ganz gross behaupten irgendwas wurde ignoriert weilalle böse sind und wenn deine Unfähigkeit mehrfach bewiesne wurde kein Wort mehr? Sagt auch einiges aus.... Aber das hast du mit so ziemlich allen die über systemd schimpfen gemeinsam: Viel Meinung für bei wenig Ahnung
Auch wir verwenden hier Arch, wegen der "Ursprünglichkeit".
Was wir aber hassen, ist die Arroganz der Systemd Protagonisten, erstmal alle Fehler beim Anwender/Admin zu suchen.
Was uns hier am meisten geärgert hat:
- defekte mount einbindung aus der fstab
-- /home ist via NFS gemounted,
-- /home/$user/[.local|.cache] sind btrfs subvols um dein DDOS gegen den NFS Server zu vermeiden, sonst liegt bei Arbeitsbegin, wenn die User hochfahren und einloggen der NFS server in der Ecke ...
Hier zeigen sich fatale Fehler:
1. /home mounted nicht, weil netwok.target falsch "online" meldet
2. obwohl /home nicht gemountet ist, werden fröhlich die /home/$user/.local mount eingehängt ...
- systemd-networkd-wait-online ist schlicht defekt:
-- unzuverlässige Netzwerk Aktivierung beim Booten
-- False Positive "Network up/Online" detection
-- defekte Link Detection spziell wenn Bridged/Bonded devices im Spiel sind
Von network.target, systemd-networkd und systemd-networkd-wait-online abhängige units knallen dann total.
Bug gemeldet, und von Poettering ignoriert ... seit 2! Jahren offen
> /home mounted nicht, weil netwok.target falsch "online" meldet
Vielleicht mal versuchen den Unterschied zwischen "network-online.target" und "netwok.target" verstehen dann wird es einfacher!
Mein "network-wan.service" der für eine DHCP-Adresse und Bridges sorgt hat "WantedBy=network.target", ist also Teil des "network.target" und wenn das und alles andere in "network.target" fertig ist kommt "network-online.target" zum Tragen
Und ja das macht Sinn und Nein mit sysvinitscripts war das nicht besser sondern nur scheisse langsam und im worst case ist der komplette Bootvorgang hängen geblieben
Und zu
> obwohl /home nicht gemountet ist, werden fröhlich die /home/$user/.local mount eingehängt
Einfach mal die Dokus lesen, Condition* funktiniert fehlerfrei, seit Jahren, wenn es komplexer wird ist /etc/fstab schlichtweg das falsche Tool, dafür gibt es mount-units in denen du DInge ausdrücken kannst die die fstab im Traum nicht hergibt
Euer Hauptproblem scheint zu sein dass ihr euch eben nicht wirklich eingearbeitet habt und gerne alles wie früher hättet, wenn man mal wirklich die Konzepte hinter systemd verstanden hat ist das wesentlich einfacher zu handhaben als das Geschiss von Shellscripts die alle ihre eigene Semantik haben und voller Workarounds sind die sich auch noch zwicshen Distributionen unterscheiden
ConditionArchitecture=, ConditionVirtualization=, ConditionHost=, ConditionKernelCommandLine=, ConditionKernelVersion=, ConditionSecurity=, ConditionCapability=, ConditionACPower=, ConditionNeedsUpdate=, ConditionFirstBoot=, ConditionPathExists=, ConditionPathExistsGlob=, ConditionPathIsDirectory=, ConditionPathIsSymbolicLink=, ConditionPathIsMountPoint=, ConditionPathIsReadWrite=, ConditionDirectoryNotEmpty=, ConditionFileNotEmpty=, ConditionFileIsExecutable=, ConditionUser=, ConditionGroup=, ConditionControlGroupController=
Na dann Link mal diesen Bugreport...
EDIT:
Hab den Bugreport selbst gefunden und wie vermutet sind nahezu alle von dir gemeldeten Probleme auf zwei Ursachen zurück zu führen. Erstens werden Abhängigkeiten unzureichend oder sogar falsch definiert was bei einem parallelen boot wie systemd ihn verwendet nicht funktionieren kann. Und zum zweiten ist deine mount-Konfiguration so komplex das die fstab bei einem parallelen boot schlicht der falsche Platz ist um so etwas zu konfigurieren.
EDIT2:
Das erste was du in den Griff bekommen müsstest wäre das was du in network.target und network-online.target "installiert" hast. Bei meinen Client-Rechnern ist es (in beiden Traget's) der NetworkManager und bei den Servern systemd-networkd. Und eigentlich funktionieren beide einwandfrei so lange ihnen kein anderes Tool (wie zum Beispiel eben libvirt) dazwischen funkt. Es gibt im Internet etliche Anleitungen darüber wie man systemd-networkd und libvirt fehlerfrei kombiniert und es wäre wohl nicht verkehrt sich die mal anzusehen.
Das zweite sind die etlichen in einander verschachtelten Einträge aus deiner fstab. Abgesehen von root, boot und swap müsste jeder Eintrag daraus in ein von dir erstelltes mount-Unit mit sauber definierten Abhängigkeiten (also mit korrekten "Requires" und "After" Optionen in der Unit-Sektion) umziehen. Der Generator den systemd für die Einträge aus der fstab-Datei anbietet ist nicht für ein so komplexes Gebilde wie das deine programmiert worden und sollte es auch nicht.
Ich kann ja deine Frustration zwar verstehen aber "ignoriert" hat dich niemand. So wie ich das sehe hat man trotz der Ausgangslage versucht dir zu helfen... Dieser Beitrag wurde 6 mal editiert. Zuletzt am 29. Okt 2018 um 12:30.Und nur damit du es verstehst:
After=network-online.target
Requires=network-online.target
Das sind die beiden Zeilen die deinem Service sagen "Du startest wenn das Netzwerk wirklich da ist", "Von network.target, systemd-networkd und systemd-networkd-wait-online abhängige units knallen dann total" ist damit reiner Bullshit weil du nicht von einzelnen Diensten abhängig bist sondern von Targets und da solltest du halt auch die richtigen benutzen
/usr/lib/systemd/system/systemd-networkd-wait-online.service:
[Install]
WantedBy=network-online.target
Und da sind wir wieder am Beginn: Basics verstehen dann klappt das auch weil "systemd-networkd-wait-online.service" ist ein SUBSET von "network-online.target"
Erst ganz gross behaupten irgendwas wurde ignoriert weilalle böse sind und wenn deine Unfähigkeit mehrfach bewiesne wurde kein Wort mehr? Sagt auch einiges aus.... Aber das hast du mit so ziemlich allen die über systemd schimpfen gemeinsam: Viel Meinung für bei wenig Ahnung