systemd ignoriert "disabled"

***@zoo:~# systemctl is-enabled restic-server
disabled

Wird trotzdem x-fach beim booten gestartet:

Loading Image...

WTF?!

--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/

Tim Ritberg

2024-11-12 14:05:37 UTC

Antworten

Post by Ulli Horlacher
disabled
https://fex.rus.uni-stuttgart.de/fop/H7Kdib9u/X-20241112114314.png
WTF?!

Ja so ist das. Ich habe gelernt, das "mask" hilft...

Tim

Marc Haber

2024-11-12 14:16:47 UTC

Antworten

Post by Ulli Horlacher
disabled

Wenn Abhängigkeiten den Service anfordern, wird er gestartet.

Disabled != Masked.

Grüße
Marc

Ulli Horlacher

2024-11-12 20:30:27 UTC

Antworten

Post by Ulli Horlacher
disabled

Wenn Abhängigkeiten den Service anfordern, wird er gestartet.
Disabled != Masked.

Wie krieg ich raus, wer das anfordert?

Und wie krieg ich den mask-Status raus?
systemctl is-enabled gibts.
systemctl is-masked gibts nicht.

Undw as ist der Unterschied zwischen:
systemctl enable restic-server
systemctl reenable restic-server

Das ist doch MIST hoch drei!

Marco Moock

2024-11-12 20:37:40 UTC

Antworten

Post by Ulli Horlacher
disabled

Wenn Abhängigkeiten den Service anfordern, wird er gestartet.
Disabled != Masked.

Wie krieg ich raus, wer das anfordert?

***@ryz:~$ systemctl list-dependencies --reverse NetworkManager
NetworkManager.service
● ├─NetworkManager-wait-online.service
● └─multi-user.target
● └─graphical.target

Post by Ulli Horlacher
Und wie krieg ich den mask-Status raus?

unmask

Post by Ulli Horlacher
systemctl enable restic-server
systemctl reenable restic-server

Ein Blick in die Manpage ist da lehrreich:

reenable UNIT…
Gibt eine oder mehrere Units erneut frei, wie dies auf der
Befehlszeile angegeben ist. Dies ist eine Kombination von
disable und enable und ist nützlich, um die Symlinks, mit der
eine Unit-Datei freigegeben wird, auf die in seinem Abschnitt
»[Install]« konfigurierten Vorgaben zurückzusetzen. Dieser
Befehl erwartet nur einen Unit-Namen und akzeptiert keine Pfade
zu Unit-Dateien.

--
Gruß
Marco

Spam und Werbung bitte an
***@nirvana.admins.ws

Ulli Horlacher

2024-11-12 21:31:34 UTC

Antworten

Post by Marc Haber
Wenn Abhängigkeiten den Service anfordern, wird er gestartet.

Wie krieg ich raus, wer das anfordert?

NetworkManager.service
? ??NetworkManager-wait-online.service
? ??multi-user.target
? ??graphical.target

***@zoo:~# systemctl list-dependencies --reverse restic-server
restic-server.service

Nichts weiter. Und jetzt?

Fuer was ist ueberhaupt disable da, wenn es beim booten ignoriert wird?
Das ist doch dann komplett sinnlos?

Post by Ulli Horlacher
Und wie krieg ich den mask-Status raus?

unmask

Nicht raus = ausschalten, sondern herauskriegen = Status abfragen.

Post by Ulli Horlacher
systemctl enable restic-server
systemctl reenable restic-server

reenable UNIT?
Gibt eine oder mehrere Units erneut frei, wie dies auf der
Befehlszeile angegeben ist. Dies ist eine Kombination von
disable und enable und ist nützlich, um die Symlinks, mit der
eine Unit-Datei freigegeben wird, auf die in seinem Abschnitt
»[Install]« konfigurierten Vorgaben zurückzusetzen. Dieser
Befehl erwartet nur einen Unit-Namen und akzeptiert keine Pfade
zu Unit-Dateien.

Das erklaert immer noch nicht den Unterschied zu enable.

Friedemann Stoyan

2024-11-13 03:00:02 UTC

Antworten

Post by Marc Haber
Wenn Abhängigkeiten den Service anfordern, wird er gestartet.

Wie krieg ich raus, wer das anfordert?

NetworkManager.service
? ??NetworkManager-wait-online.service
? ??multi-user.target
? ??graphical.target

restic-server.service
Nichts weiter. Und jetzt?

Vielleicht wird der Service ja auch über eine Socket-Unit aktiviert. Dann
taucht da natürlich nichts auf:

systemctl list-unit-files | grep restic

mfg Friedemann

Ulli Horlacher

2024-11-13 08:00:26 UTC

Antworten

Post by Friedemann Stoyan

Post by Marc Haber
Wenn Abhängigkeiten den Service anfordern, wird er gestartet.

Wie krieg ich raus, wer das anfordert?

NetworkManager.service
? ??NetworkManager-wait-online.service
? ??multi-user.target
? ??graphical.target

restic-server.service
Nichts weiter. Und jetzt?

Vielleicht wird der Service ja auch über eine Socket-Unit aktiviert. Dann
systemctl list-unit-files | grep restic

***@zoo:~# systemctl list-unit-files | grep -E 'restic|UNIT'
UNIT FILE STATE VENDOR PRESET
iscsi-san\x2dstore1-restic.mount generated -
nfs-restic.mount generated -
restic-server.service disabled enabled

Ich seh da keinen Socket.

Frank B

2024-11-13 15:05:52 UTC

Antworten

Post by Friedemann Stoyan

Post by Ulli Horlacher
restic-server.service
Nichts weiter. Und jetzt?

Vielleicht wird der Service ja auch über eine Socket-Unit aktiviert. Dann
systemctl list-unit-files | grep restic

UNIT FILE STATE VENDOR PRESET
iscsi-san\x2dstore1-restic.mount generated -
nfs-restic.mount generated -
restic-server.service disabled enabled
Ich seh da keinen Socket.

aber status generated: man systemctl sagt dazu:

Tabelle 1. Ausgabe von is-enabled

"generated" │ Die Unit wurde dynamisch mit einem
│ Generatorwerkzeug erstellt. Siehe
│ systemd.generator(7). Erstellte
│ Unit-Dateien können nicht freigegeben
│ werden, sie werden implizit durch ihren
│ Generator freigegeben.

Marco Moock

2024-11-13 15:07:52 UTC

Antworten

Post by Frank B
Tabelle 1. Ausgabe von is-enabled
"generated" │ Die Unit wurde dynamisch mit einem
│ Generatorwerkzeug erstellt. Siehe
│ systemd.generator(7). Erstellte
│ Unit-Dateien können nicht freigegeben
│ werden, sie werden implizit durch ihren
│ Generator freigegeben.

Sprich: Mal in /etc/init.d gucken.
Zwar ist der Generator deprecated, aber in vielen Systemen steckt der
noch drin.

--
Gruß
Marco

Spam und Werbung bitte an
***@nirvana.admins.ws

Ulli Horlacher

2024-11-13 17:10:34 UTC

Antworten

Post by Frank B
Tabelle 1. Ausgabe von is-enabled
"generated" ? Die Unit wurde dynamisch mit einem
? Generatorwerkzeug erstellt. Siehe
? systemd.generator(7). Erstellte
? Unit-Dateien können nicht freigegeben
? werden, sie werden implizit durch ihren
? Generator freigegeben.

Sprich: Mal in /etc/init.d gucken.
Zwar ist der Generator deprecated, aber in vielen Systemen steckt der
noch drin.

Da findet sich nichts mit "generator"

Kay Martinen

2024-11-13 18:35:38 UTC

Antworten

Sprich: Mal in /etc/init.d gucken.
Zwar ist der Generator deprecated, aber in vielen Systemen steckt der
noch drin.

Da findet sich nichts mit "generator"

In /etc/init.d wohl auch kaum. Ich denke wenn der lief erzeugt er die
units eher in /usr

Finde ich auch nicht so toll das man da dann auch noch auf die suche
gehen müsste.

Und es würde mich auch nicht wundern wenn man "generator" nur IN den
erzeugen dateien findet und nicht im namen derselben.

Und dann wohlmöglich auch nur als "generated from..." oder so.

Bye/
/Kay

--
Posted via Leafnode

Marco Moock

2024-11-13 19:13:26 UTC

Antworten

Sprich: Mal in /etc/init.d gucken.
Zwar ist der Generator deprecated, aber in vielen Systemen steckt
der noch drin.

Da findet sich nichts mit "generator"

Der Generator ist dazu da, systemd-units aus SysVinit-Skripten zu
erstellen.
Die wissen davon nix.
Ist nur ne Art Abwärtskompatibilität, damit die alten Initskripte noch
genutzt werden können.

--
Gruß
Marco

Spam und Werbung bitte an
***@nirvana.admins.ws

Ulli Horlacher

2024-11-14 09:12:30 UTC

Antworten

Post by Marco Moock
Der Generator ist dazu da, systemd-units aus SysVinit-Skripten zu
erstellen.

/etc/systemd/system/restic-server.service ist kein SysVinit-Skript

Marc Haber

2024-11-14 08:33:11 UTC

Antworten

Sprich: Mal in /etc/init.d gucken.
Zwar ist der Generator deprecated, aber in vielen Systemen steckt der
noch drin.

Da findet sich nichts mit "generator"

Du solltest Dich wirklich mal mit systemd beschäftigen. Dinge sind
nicht alleine deswegen Mist weil man sie nicht beherrscht.

Grüße
Marc

Thomas Dorner

2024-11-13 20:58:32 UTC

Antworten

Post by Ulli Horlacher
UNIT FILE STATE VENDOR PRESET
iscsi-san\x2dstore1-restic.mount generated -
nfs-restic.mount generated -
restic-server.service disabled enabled
Ich seh da keinen Socket.

Ich sehe da zwei mounts. Was ergibt
systemctl list-dependencies nfs-restic.mount
systemctl list-dependencies iscsi-san\x2dstore1-restic.mount
?

Generierte mounts werden möglicherweise nicht in allen Fällen mit
"list-dependencies --reverse" gefunden.

Viele Grüße, Thomas

--
Adresse gilt nur kurzzeitig!

Ulli Horlacher

2024-11-14 09:26:07 UTC

Antworten

Post by Thomas Dorner

Post by Ulli Horlacher
UNIT FILE STATE VENDOR PRESET
iscsi-san\x2dstore1-restic.mount generated -
nfs-restic.mount generated -
restic-server.service disabled enabled
Ich seh da keinen Socket.

Ich sehe da zwei mounts.

Die haben nichts mit /etc/systemd/system/restic-server.service zu tun,
ausser dass der restic Server spaeter dort drauf zugreift.
Davon weiss systemd aber nichts und kann auch keine Abhaengkeiten
generieren.
Das ist ueber einen symlink realisiert:

***@zoo:~: ll data
lrwxrwxrwx restic backup - 2024-05-10 09:17:02 data -> /nfs/restic/

Was ergibt

Post by Thomas Dorner
systemctl list-dependencies nfs-restic.mount
systemctl list-dependencies iscsi-san\x2dstore1-restic.mount

***@zoo:~# systemctl list-dependencies nfs-restic.mount
nfs-restic.mount
* |--.mount
* |-system.slice
* `-network-online.target
* `-networking.service

***@zoo:~# systemctl list-dependencies 'iscsi-san\x2dstore1-restic.mount'
iscsi-san\x2dstore1-restic.mount
* |--.mount
* |-dev-mapper-mpathc\x2dpart1.device
* `-system.slice

Schon wieder dieses *ZENSIERTE* \ im filenamen!

Aber wie gesagt: hat nichts mit restic-server.service zu tun.

Marco Moock

2024-11-13 14:21:13 UTC

Antworten

Post by Marc Haber
Wenn Abhängigkeiten den Service anfordern, wird er gestartet.

Wie krieg ich raus, wer das anfordert?

NetworkManager.service
? ??NetworkManager-wait-online.service
? ??multi-user.target
? ??graphical.target

restic-server.service
Nichts weiter. Und jetzt?
Fuer was ist ueberhaupt disable da, wenn es beim booten ignoriert
wird? Das ist doch dann komplett sinnlos?

Mit enable wird dafür gesorgt, dass der Dienst auf jeden Fall gestartet
wird (glaub multi-user.target oder sog).

Mit disable wird das deaktiviert, der Dienst kann aber manuell oder
durch eine Abhängigkeit jederzeit gestartet werden. Mit mask wird da
verhindert.

Post by Ulli Horlacher
Und wie krieg ich den mask-Status raus?

unmask

Nicht raus = ausschalten, sondern herauskriegen = Status abfragen.

Gerade getestet:
Etwas umständlich, aber es wird angezeigt.

***@ryz:~$ systemctl status sendmail
● sendmail.service
Loaded: masked (Reason: Unit sendmail.service is masked.)

Post by Ulli Horlacher
systemctl enable restic-server
systemctl reenable restic-server

reenable UNIT?
Gibt eine oder mehrere Units erneut frei, wie dies auf
der Befehlszeile angegeben ist. Dies ist eine Kombination von
disable und enable und ist nützlich, um die Symlinks, mit der
eine Unit-Datei freigegeben wird, auf die in seinem Abschnitt
»[Install]« konfigurierten Vorgaben zurückzusetzen. Dieser
Befehl erwartet nur einen Unit-Namen und akzeptiert keine
Pfade zu Unit-Dateien.

Das erklaert immer noch nicht den Unterschied zu enable.

|This is a combination of disable and enable

Ohne es geprüft zu haben: Vermutlich führt das en disable und dann ein
enable auf die Unit aus.

--
Gruß
Marco

Spam und Werbung bitte an
***@nirvana.admins.ws

Ulli Horlacher

2024-11-13 14:26:22 UTC

Antworten

Post by Ulli Horlacher
Fuer was ist ueberhaupt disable da, wenn es beim booten ignoriert
wird? Das ist doch dann komplett sinnlos?

Mit disable wird das deaktiviert, der Dienst kann aber manuell oder
durch eine Abhängigkeit jederzeit gestartet werden.

Das erklaert meine Frage nicht.
Wenn der Dienst trotz des disable gestartet werden kann (zB beim booten),
fuer was ist dann disable gut? Es hat doch NULL Auswirkung!

Arno Welzel

2024-11-13 14:51:01 UTC

Antworten

Post by Ulli Horlacher
Fuer was ist ueberhaupt disable da, wenn es beim booten ignoriert
wird? Das ist doch dann komplett sinnlos?

Mit disable wird das deaktiviert, der Dienst kann aber manuell oder
durch eine Abhängigkeit jederzeit gestartet werden.

Das erklaert meine Frage nicht.
Wenn der Dienst trotz des disable gestartet werden kann (zB beim booten),
fuer was ist dann disable gut? Es hat doch NULL Auswirkung!

Es hat die Auswirkung, dass der Dienst beim Boot nicht gestartet wird,
wenn es keinerlei Abhängigkeiten gibt, die den Dienst brauchen. Sonst
würden nämlich immer *alle* Dienste starten, nur weil es eine
Systemd-Unit dafür gibt.

--
Arno Welzel
https://arnowelzel.de

Ulli Horlacher

2024-11-13 15:01:08 UTC

Antworten

Post by Ulli Horlacher
Fuer was ist ueberhaupt disable da, wenn es beim booten ignoriert
wird? Das ist doch dann komplett sinnlos?

Mit disable wird das deaktiviert, der Dienst kann aber manuell oder
durch eine Abhängigkeit jederzeit gestartet werden.

Das erklaert meine Frage nicht.
Wenn der Dienst trotz des disable gestartet werden kann (zB beim booten),
fuer was ist dann disable gut? Es hat doch NULL Auswirkung!

Es hat die Auswirkung, dass der Dienst beim Boot nicht gestartet wird,
wenn es keinerlei Abhängigkeiten gibt, die den Dienst brauchen.

Ich hab keine Abhaengigkeit und trotzdem wird der Dienst gestartet.

Arno Welzel

2024-11-13 15:21:07 UTC

Antworten

Post by Ulli Horlacher
Fuer was ist ueberhaupt disable da, wenn es beim booten ignoriert
wird? Das ist doch dann komplett sinnlos?

Mit disable wird das deaktiviert, der Dienst kann aber manuell oder
durch eine Abhängigkeit jederzeit gestartet werden.

Das erklaert meine Frage nicht.
Wenn der Dienst trotz des disable gestartet werden kann (zB beim booten),
fuer was ist dann disable gut? Es hat doch NULL Auswirkung!

Es hat die Auswirkung, dass der Dienst beim Boot nicht gestartet wird,
wenn es keinerlei Abhängigkeiten gibt, die den Dienst brauchen.

Ich hab keine Abhaengigkeit und trotzdem wird der Dienst gestartet.

Da das rein technisch unmöglich ist, wird es eine Abhängigkeit geben,
die Du nur nicht leicht herausfinden kannst. Nein, ich kann Dir da auf
Anhieb leider auch nicht weiter helfen, als die Hinweise, die hier schon
gegeben wurden.

--
Arno Welzel
https://arnowelzel.de

Ulli Horlacher

2024-11-13 17:11:51 UTC

Antworten

Post by Ulli Horlacher
Ich hab keine Abhaengigkeit und trotzdem wird der Dienst gestartet.

Und genau wegen so was ist systemd MIST.
Obskur und nicht nachvollziehbar.

Arno Welzel

2024-11-14 07:48:18 UTC

Antworten

Post by Ulli Horlacher
Ich hab keine Abhaengigkeit und trotzdem wird der Dienst gestartet.

Und genau wegen so was ist systemd MIST.
Obskur und nicht nachvollziehbar.

Dann stelle die Unit halt komplett ab - also so, dass sie auch nicht
gestartet wird, wenn irgendwer das gerne hätte und nicht nur ohne
automatischen Start beim Booten:

systemctl mask restic-server.service

Oder alternativ manuell einen symbolischen Link auf /dev/null anlegen:

ln -s /dev/null /etc/systemd/system/restic-server.service

Siehe auch: <https://0pointer.de/blog/projects/three-levels-of-off>

--
Arno Welzel
https://arnowelzel.de

Ulli Horlacher

2024-11-14 08:57:08 UTC

Antworten

Post by Arno Welzel
Dann stelle die Unit halt komplett ab - also so, dass sie auch nicht
gestartet wird, wenn irgendwer das gerne hätte und nicht nur ohne
systemctl mask restic-server.service

***@zoo:~# systemctl mask restic-server
Failed to mask unit: File /etc/systemd/system/restic-server.service already exists.

Post by Arno Welzel
ln -s /dev/null /etc/systemd/system/restic-server.service

Dann ist der Service fuer immer weg (muesste ihn vorher manuell sichern)
und ich kann ihn auch nicht mehr manuell so einfach starten.
Ich will aber NUR, dass er beim booten nicht automatisch gestartet wird.
systemd sieht das aber anscheinend nicht vor.

Post by Arno Welzel
Siehe auch: <https://0pointer.de/blog/projects/three-levels-of-off>

Posted on Mi 02 März 2011

Das duerfte kaum noch aktuell sein.

Marc Haber

2024-11-14 09:42:57 UTC

Antworten

Post by Arno Welzel
Dann stelle die Unit halt komplett ab - also so, dass sie auch nicht
gestartet wird, wenn irgendwer das gerne hätte und nicht nur ohne
systemctl mask restic-server.service

Failed to mask unit: File /etc/systemd/system/restic-server.service already exists.

Wer hat das Ding da hingelegt? Die Distribution wird das nicht gewesen
sein.

Post by Arno Welzel
Siehe auch: <https://0pointer.de/blog/projects/three-levels-of-off>

Posted on Mi 02 März 2011
Das duerfte kaum noch aktuell sein.

Ist es aber.

Ulli Horlacher

2024-11-14 09:48:31 UTC

Antworten

Post by Arno Welzel
Dann stelle die Unit halt komplett ab - also so, dass sie auch nicht
gestartet wird, wenn irgendwer das gerne hätte und nicht nur ohne
systemctl mask restic-server.service

Failed to mask unit: File /etc/systemd/system/restic-server.service already exists.

Wer hat das Ding da hingelegt? Die Distribution wird das nicht gewesen
sein.

Ich (wie schon geschrieben).
Die Distribution enthaelt keinen restic-server.
Wo haette ich es sonst ablegen sollen?

Ahh.. du bringst mich da auf eine Idee:
Ich loesche den Quatsch und mach aus restic-server.service ein
SysV-init-Skript.
Der funktioniert dann deterministisch.

Dietz Proepper

2024-11-14 13:47:09 UTC

Antworten

Post by Ulli Horlacher
Ich loesche den Quatsch und mach aus restic-server.service ein
SysV-init-Skript.
Der funktioniert dann deterministisch.

Nur für wie lang ...

--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled. - Richard P. Feynman, 1987

Ulli Horlacher

2024-11-14 14:00:25 UTC

Antworten

Post by Ulli Horlacher
Ich loesche den Quatsch und mach aus restic-server.service ein
SysV-init-Skript.
Der funktioniert dann deterministisch.

Nur für wie lang ...

Fuer wenigstens 10 Jahre. Reicht.

Marc Haber

2024-11-14 14:57:11 UTC

Antworten

Post by Arno Welzel
Dann stelle die Unit halt komplett ab - also so, dass sie auch nicht
gestartet wird, wenn irgendwer das gerne hätte und nicht nur ohne
systemctl mask restic-server.service

Failed to mask unit: File /etc/systemd/system/restic-server.service already exists.

Wer hat das Ding da hingelegt? Die Distribution wird das nicht gewesen
sein.

Ich (wie schon geschrieben).
Die Distribution enthaelt keinen restic-server.
Wo haette ich es sonst ablegen sollen?

Der Ort ist für lokal erzeugte Units schon richtig. Nur kann man diese
dann halt nicht maskieren (maskieren würde übrigens auch das manuelle
Starten verhindern).

Du hast jetzt vermutlich fünfmal mehr Zeit mit "Systemd ist Mist"
verbracht als damit zu verstehen was auf Deinem System wirklich
passiert.

Post by Ulli Horlacher
Ich loesche den Quatsch und mach aus restic-server.service ein
SysV-init-Skript.
Der funktioniert dann deterministisch.

Deine Kollegen und Nachfolger werden entweder über Dich lachen oder
Dich hassen.

Grüße
Marc

Ulli Horlacher

2024-11-14 15:03:54 UTC

Antworten

Post by Ulli Horlacher
Failed to mask unit: File /etc/systemd/system/restic-server.service already exists.

Der Ort ist für lokal erzeugte Units schon richtig. Nur kann man diese
dann halt nicht maskieren (maskieren würde übrigens auch das manuelle
Starten verhindern).

Somit kann man mit systemd den automatischen Start beim booten nicht
verhindern. Murks.

Post by Marc Haber
Du hast jetzt vermutlich fünfmal mehr Zeit mit "Systemd ist Mist"
verbracht als damit zu verstehen was auf Deinem System wirklich
passiert.

Ich hab jetzt verstanden, dass es mit systemd nicht geht. Es gibt keine
Loesung damit. Also werde ich ein SysV-Init-Skript nehmen. Das
funktioniert dann. Schon was gelernt.

Post by Marc Haber
Deine Kollegen und Nachfolger werden entweder über Dich lachen oder
Dich hassen.

Weil sie systemd auch nicht verstehen.

Marc Haber

2024-11-14 15:23:47 UTC

Antworten

Post by Ulli Horlacher
Failed to mask unit: File /etc/systemd/system/restic-server.service already exists.

Der Ort ist für lokal erzeugte Units schon richtig. Nur kann man diese
dann halt nicht maskieren (maskieren würde übrigens auch das manuelle
Starten verhindern).

Somit kann man mit systemd den automatischen Start beim booten nicht
verhindern.

Ex falso Quodlibet. Der erste Schritt beim Debugging ist, dem Problem
auf den Grund zu gehen.

Post by Marc Haber
Du hast jetzt vermutlich fünfmal mehr Zeit mit "Systemd ist Mist"
verbracht als damit zu verstehen was auf Deinem System wirklich
passiert.

Ich hab jetzt verstanden, dass es mit systemd nicht geht.

Das ist nicht richtig.

Post by Ulli Horlacher
Schon was gelernt.

Was falsches gelernt.

Post by Marc Haber
Deine Kollegen und Nachfolger werden entweder über Dich lachen oder
Dich hassen.

Weil sie systemd auch nicht verstehen.

Das kann man lernen. Und man sollte es auch. Es hat Vorteile.

Unix kann man auch lernen. Dessen Lernkurve ist steiler.

Grüße
Marc

Ralph Aichinger

2024-11-13 15:27:16 UTC

Antworten

Post by Ulli Horlacher
Ich hab keine Abhaengigkeit und trotzdem wird der Dienst gestartet.

Vermutlich hast du welche, noch nocht nicht enteckt, dass du sie hast?

/ralph

Ulli Horlacher

2024-11-13 17:13:49 UTC

Antworten

Post by Ulli Horlacher
Ich hab keine Abhaengigkeit und trotzdem wird der Dienst gestartet.

Vermutlich hast du welche, noch nocht nicht enteckt, dass du sie hast?

Dann gibts keinen Befehl, der Abhaengikeiten auflistet. Auch nicht besser.
systemd ist und bleibt Mist.

Marco Moock

2024-11-13 19:15:25 UTC

Antworten

Post by Ulli Horlacher
Ich hab keine Abhaengigkeit und trotzdem wird der Dienst
gestartet.

Vermutlich hast du welche, noch nocht nicht enteckt, dass du sie hast?

Dann gibts keinen Befehl, der Abhaengikeiten auflistet. Auch nicht
besser. systemd ist und bleibt Mist.

Doch, gibt es, siehe die vorherigen Posts.
Schaue mal, ob das ein sysvinit-Skript ist, was unter /etc/init.d liegt.
Was liegt da bei dir überhaupt?

--
Gruß
Marco

Spam und Werbung bitte an
***@nirvana.admins.ws

Ulli Horlacher

2024-11-14 08:58:51 UTC

Antworten

Post by Ulli Horlacher
Ich hab keine Abhaengigkeit und trotzdem wird der Dienst
gestartet.

Vermutlich hast du welche, noch nocht nicht enteckt, dass du sie hast?

Dann gibts keinen Befehl, der Abhaengikeiten auflistet. Auch nicht
besser. systemd ist und bleibt Mist.

Doch, gibt es, siehe die vorherigen Posts.

Siehe meine Antwort darauf: es wird NICHTS gelistet.

Post by Marco Moock
Schaue mal, ob das ein sysvinit-Skript ist, was unter /etc/init.d liegt.
Was liegt da bei dir überhaupt?

Von mir angelegt:
/etc/systemd/system/restic-server.service

Kay Martinen

2024-11-13 22:22:26 UTC

Antworten

Post by Ulli Horlacher
Ich hab keine Abhaengigkeit und trotzdem wird der Dienst gestartet.

Vermutlich hast du welche, noch nocht nicht enteckt, dass du sie hast?

Dann gibts keinen Befehl, der Abhaengikeiten auflistet.

Der Fairness halber: Gibt es den denn bei SysVInit?
Die Nummerierung der Start-links sagt/legt nur die Zeitliche Folge fest.

Und ob tools wie insserv das leisten hat mich nie so weit interessiert,
aber das scheint der einzige Ansatz zu sein, neben in kommentaren der
scripte versteckten "depends" u.a. (was evtl. auf's gleiche hinaus läuft)

Aber eine art "zeig mir die abhängigkeiten von 'network'" als einzeiler
für die bash???

Bye/
/Kay

--
Posted via Leafnode

Ulli Horlacher

2024-11-14 09:00:54 UTC

Antworten

Post by Kay Martinen

Post by Ulli Horlacher
Ich hab keine Abhaengigkeit und trotzdem wird der Dienst gestartet.

Vermutlich hast du welche, noch nocht nicht enteckt, dass du sie hast?

Dann gibts keinen Befehl, der Abhaengikeiten auflistet.

Der Fairness halber: Gibt es den denn bei SysVInit?
Die Nummerierung der Start-links sagt/legt nur die Zeitliche Folge fest.

Das ist deterministisch und einfach zu verstehen und zu debuggen und nicht
so ein unueberschaubarer Abhaengigkeitswust wie bei systemd, der auch mal
zu Ringschluessen fuehren kann.

Marco Moock

2024-11-14 15:26:37 UTC

Antworten

Post by Kay Martinen

Post by Ulli Horlacher
Dann gibts keinen Befehl, der Abhaengikeiten auflistet.

Der Fairness halber: Gibt es den denn bei SysVInit?

Mir wäre sowas nicht bekannt.
Da zählt die Reihenfolge und wer da was einrichtet, muss dafür sorgen,
dass die Reihenfolge passt. Ebenfalls muss man dann ggf. manuell
prüfen, ob der Dienst auch läuft, da sonst der eigene Dienst kracht,
ein Timeout bekommt etc.

Für den Admin ggf. mehr Arbeit als systemd.

--
Gruß
Marco

Spam und Werbung bitte an
***@nirvana.admins.ws

Marco Moock

2024-11-13 15:06:38 UTC

Antworten

Post by Ulli Horlacher
Fuer was ist ueberhaupt disable da, wenn es beim booten ignoriert
wird? Das ist doch dann komplett sinnlos?

Mit disable wird das deaktiviert, der Dienst kann aber manuell oder
durch eine Abhängigkeit jederzeit gestartet werden.

Das erklaert meine Frage nicht.
Wenn der Dienst trotz des disable gestartet werden kann (zB beim
booten), fuer was ist dann disable gut? Es hat doch NULL Auswirkung!

Nehmen wir mal an, du willst xdm beim Systemstart automatisch gestartet
haben. Solange kein Dienst das auf Wants= oder so setzt, wird der nicht
gestartet. Mit enable kannst du den jetzt zum multi-user.target
hinzufügen. Beim Systemstart wird dann alles gestartet, was dieses
target haben will. Das macht enable. Disable entfernt das von da wieder.

Hier mal ein Teil der Zeile bei mir:
Wants=systemd-ask-password-wall.path cron.service
inetutils-inetd.service wsdd.service cups.service
systemd-logind.service dbus.service ssh.service sysfsutils.service
inetutils-syslogd.service unattended-upgrades.service

Es gibt mehrere Stellen, an denen ein Wants stehen kann. Das kann ein
Dienst selbst sein, der wiederum in nem Target steht oder halt das
Target selbst hat den im Wants drinstehen.

Wenn du den jedweden Start auf jeden Fall verhindern willst, nimm
mask.

--
Gruß
Marco

Spam und Werbung bitte an
***@nirvana.admins.ws

Ralph Aichinger

2024-11-13 15:26:26 UTC

Antworten

Post by Ulli Horlacher
Das erklaert meine Frage nicht.
Wenn der Dienst trotz des disable gestartet werden kann (zB beim booten),
fuer was ist dann disable gut? Es hat doch NULL Auswirkung!

Dass er von sich aus nicht automatisch gestartet wird?

/ralph

Kay Martinen

2024-11-13 18:47:42 UTC

Antworten

Post by Ulli Horlacher
Das erklaert meine Frage nicht.
Wenn der Dienst trotz des disable gestartet werden kann (zB beim booten),
fuer was ist dann disable gut? Es hat doch NULL Auswirkung!

Dass er von sich aus nicht automatisch gestartet wird?

Und was passiert dann eigentlich wenn man eine unit auf masked setzt und
deren start damit verhindert, die aber eine abhängigkeit zu einer
anderen unit hat. Fällt die letztere dann auf die Fresse weil die
Abhängigkeit nicht erfüllt werden kann - oder wird die maskierte dann
ggf. doch gestartet damit auch ja Erfolg zurück gemeldet werden kann?

Beispiel (vielleicht):

Ich hab neulich auf einem kleinen Rechner mit XFCE von Graphical-Target
auf Default-Target um gestellt weil ich den Desktop mit login-manager
u.a. eben NICHT mehr automatisch starten lassen wollte um RAM und
Bootzeit zu sparen. Aber nach dem Reboot war der Grafische login immer
noch gestartet und führte auch zum Desktop. ==> Failed im Sinne der Absicht!

Hätte ich da noch was maskieren sollen oder noch ein Weiteres Target o.
Unit suchen die den dann doch startet?

'telinit 3' hätte es EINFACH getan! Oder (permanent) die Änderung des
Default-runlevels. Ebenso ein 'startX' unter meinem User login wenn ich
doch Desktop bräuchte. Oder (je nach Setup) z.b. auch ein 'telinit 4'

Bye/
/Kay

--
Posted via Leafnode

Marco Moock

2024-11-13 19:16:41 UTC

Antworten

Post by Kay Martinen
Und was passiert dann eigentlich wenn man eine unit auf masked setzt
und deren start damit verhindert, die aber eine abhängigkeit zu einer
anderen unit hat. Fällt die letztere dann auf die Fresse weil die
Abhängigkeit nicht erfüllt werden kann - oder wird die maskierte dann
ggf. doch gestartet damit auch ja Erfolg zurück gemeldet werden kann?

Die abhängige Unit kann nicht gestartet werden.

--
Gruß
Marco

Spam und Werbung bitte an
***@nirvana.admins.ws

Marc Haber

2024-11-12 21:13:35 UTC

Antworten

Post by Ulli Horlacher
Das ist doch MIST hoch drei!

Es ist nur anders.

Tim Ritberg

2024-11-13 08:34:25 UTC

Antworten

Post by Ulli Horlacher
Das ist doch MIST hoch drei!

Es ist nur anders.

Du sagt es, systemd; nicht besser, nur anders :-D

Tim

Marc Haber

2024-11-13 08:53:15 UTC

Antworten

Post by Ulli Horlacher
Das ist doch MIST hoch drei!

Es ist nur anders.

Du sagt es, systemd; nicht besser, nur anders :-D

In vielen Dingen ist es auch besser. Aber: All Software sucks.

Und Initscripte sucken mehr.

Ulli Horlacher

2024-11-13 12:10:32 UTC

Antworten

Post by Ulli Horlacher
Das ist doch MIST hoch drei!

Es ist nur anders.

Du sagt es, systemd; nicht besser, nur anders :-D

In vielen Dingen ist es auch besser. Aber: All Software sucks.
Und Initscripte sucken mehr.

Die machen DEUTLICH weniger Problem UND sind viel besser zu verstehen und
zu debuggen.

Bei systemd ist das Meiste intransparent und vieles funktioniert schlecht
oder gar nicht. Debugging ist schwierig bis unmoeglich.

Aktuelles Beispiel: niemand konnte mir bisher sagen warum systemd einen
disabled Service beim booten ein dutzend mal starten will.

Ich hab Server, die brauchen zum reboot 10 Minuten "dank" systemd.
Manchmal bleiben sie dabei auch stehen, dann hilft nur Reset.

Ralph Aichinger

2024-11-13 12:47:03 UTC

Antworten

Post by Ulli Horlacher
Die machen DEUTLICH weniger Problem UND sind viel besser zu verstehen und
zu debuggen.

LOL, nein. Vor allem das letztere nicht.

Post by Ulli Horlacher
Bei systemd ist das Meiste intransparent und vieles funktioniert schlecht
oder gar nicht. Debugging ist schwierig bis unmoeglich.

Okay? Alle großen Distributionen verwenden es, und die Welt ist noch
nicht zusammengebrochen.

Post by Ulli Horlacher
Aktuelles Beispiel: niemand konnte mir bisher sagen warum systemd einen
disabled Service beim booten ein dutzend mal starten will.

Und das kriegst du mit Shellskripten nicht hin?
Systemd macht auch nur das, was man ihm in Units anschafft.
Genau wie SysV-Init.

Hast du einen Bug zu dem beschriebenen Verfahren?

Post by Ulli Horlacher
Ich hab Server, die brauchen zum reboot 10 Minuten "dank" systemd.
Manchmal bleiben sie dabei auch stehen, dann hilft nur Reset.

Das kannst du auch mit SysV-Init haben.

/ralph

Ulli Horlacher

2024-11-13 14:20:17 UTC

Antworten

Post by Ulli Horlacher
Ich hab Server, die brauchen zum reboot 10 Minuten "dank" systemd.
Manchmal bleiben sie dabei auch stehen, dann hilft nur Reset.

Das kannst du auch mit SysV-Init haben.

Hab ich aber nicht. Ich hab NUR Probleme mit systemd und dafuer auch
keine Loesungen.

Arno Welzel

2024-11-13 12:59:35 UTC

Antworten

Ulli Horlacher, 2024-11-13 13:10:

[...]

Post by Ulli Horlacher
Aktuelles Beispiel: niemand konnte mir bisher sagen warum systemd einen
disabled Service beim booten ein dutzend mal starten will.

Weil "disabled" nur bedeutet "Service nicht direkt beim boot starten"
und nicht "Service niemals starten, auch dann nicht, wenn jemand das
explizit so haben will".

Post by Ulli Horlacher
Ich hab Server, die brauchen zum reboot 10 Minuten "dank" systemd.
Manchmal bleiben sie dabei auch stehen, dann hilft nur Reset.

Hatte ich auch schon mit SysV init.

--
Arno Welzel
https://arnowelzel.de

Ulli Horlacher

2024-11-13 14:22:11 UTC

Antworten

Post by Arno Welzel
[...]

Post by Ulli Horlacher
Aktuelles Beispiel: niemand konnte mir bisher sagen warum systemd einen
disabled Service beim booten ein dutzend mal starten will.

Weil "disabled" nur bedeutet "Service nicht direkt beim boot starten"
und nicht "Service niemals starten, auch dann nicht, wenn jemand das
explizit so haben will".

Und wer ist nun dieser "jemand"?

Post by Ulli Horlacher
Ich hab Server, die brauchen zum reboot 10 Minuten "dank" systemd.
Manchmal bleiben sie dabei auch stehen, dann hilft nur Reset.

Hatte ich auch schon mit SysV init.

Ich nicht und selbst wenn, waere es trivial das zu debuggen.
Bei systemd Haenger hab ich keine Loesung.

Marco Moock

2024-11-13 14:23:14 UTC

Antworten

Post by Arno Welzel
[...]

Post by Ulli Horlacher
Aktuelles Beispiel: niemand konnte mir bisher sagen warum systemd
einen disabled Service beim booten ein dutzend mal starten will.

Weil "disabled" nur bedeutet "Service nicht direkt beim boot
starten" und nicht "Service niemals starten, auch dann nicht, wenn
jemand das explizit so haben will".

Und wer ist nun dieser "jemand"?

Greppe mal nach dem Dienstnamen in den Systemd-Verzeichnissen.
Ne andere Idee habe ich auch nicht mehr.

--
Gruß
Marco

Spam und Werbung bitte an
***@nirvana.admins.ws

Ulli Horlacher

2024-11-13 15:05:43 UTC

Antworten

Post by Ulli Horlacher
Aktuelles Beispiel: niemand konnte mir bisher sagen warum systemd
einen disabled Service beim booten ein dutzend mal starten will.

Weil "disabled" nur bedeutet "Service nicht direkt beim boot
starten" und nicht "Service niemals starten, auch dann nicht, wenn
jemand das explizit so haben will".

Und wer ist nun dieser "jemand"?

Greppe mal nach dem Dienstnamen in den Systemd-Verzeichnissen.

***@zoo:~# grep -lr restic /etc/systemd /lib/systemd
/etc/systemd/system/restic-server.service

Mehr kommt nicht.

Ralph Aichinger

2024-11-13 15:32:21 UTC

Antworten

Post by Ulli Horlacher
/etc/systemd/system/restic-server.service

Kannst du mal posten, was da drin steht? Das werden ja wohl nicht mehr
als 5-20 Zeilen sein?

/ralph

Ulli Horlacher

2024-11-13 17:17:45 UTC

Antworten

Post by Ulli Horlacher
/etc/systemd/system/restic-server.service

Kannst du mal posten, was da drin steht?

***@zoo:~# cat /etc/systemd/system/restic-server.service
[Unit]
Description=Restic Server
After=syslog.target
After=network.target

[Service]
Type=simple
User=restic
ExecStart=/opt/rest-server/rest-server --path /home/restic/data --private-repos --tls
Restart=always
RestartSec=5
#StandardOutput=syslog
#StandardError=syslog

[Install]
WantedBy=multi-user.target

Arno Welzel

2024-11-14 07:49:39 UTC

Antworten

Post by Ulli Horlacher
/etc/systemd/system/restic-server.service

Kannst du mal posten, was da drin steht?

[Unit]
Description=Restic Server
After=syslog.target
After=network.target
[Service]
Type=simple
User=restic
ExecStart=/opt/rest-server/rest-server --path /home/restic/data --private-repos --tls
Restart=always
RestartSec=5
#StandardOutput=syslog
#StandardError=syslog
[Install]
WantedBy=multi-user.target

Mal ganz blöd gefragt: wenn der Restic-Server sowieso nicht benutzt
werden soll, wieso ist das Ding dann überhaupt installiert?

--
Arno Welzel
https://arnowelzel.de

Ulli Horlacher

2024-11-14 09:02:44 UTC

Antworten

Post by Arno Welzel
Mal ganz blöd gefragt: wenn der Restic-Server sowieso nicht benutzt
werden soll, wieso ist das Ding dann überhaupt installiert?

Er soll NUR nicht beim booten automatisch starten, manuell schon.

Bernd

2024-11-14 08:15:52 UTC

Antworten

Post by Ulli Horlacher
/etc/systemd/system/restic-server.service

Kannst du mal posten, was da drin steht?

Ich will mich da in euren Fight nicht einmischen, aber hast du mal das
Restart=always
RestartSec=5

geprüft? Ich verstehe das so das dadurch das Programm nach jedem(!)
Beenden nach 5 Sekunden wieder gestartet wird.

<https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html>

Just my 2 cents

Bernd

Ulli Horlacher

2024-11-14 09:04:35 UTC

Antworten

Post by Bernd
Ich will mich da in euren Fight nicht einmischen, aber hast du mal das
Restart=always
RestartSec=5
geprüft? Ich verstehe das so das dadurch das Programm nach jedem(!)
Beenden nach 5 Sekunden wieder gestartet wird.

Nicht nach jedem, nur bei unbeabsichtigten Abbruch.
Mit "systemctl stop restic-server" kann man den Service anhalten.

Bernd

2024-11-14 12:25:30 UTC

Antworten

Nicht nach jedem, nur bei unbeabsichtigten Abbruch.
Mit "systemctl stop restic-server" kann man den Service anhalten.

Wenn du meinst ... für mich liest sich das so (Siehe die Tabelle im
Link) das 'always' das Pgm. IMMER neu startet.

Aber gut ... nicht mein Problem.

Bernd

Ulli Horlacher

2024-11-14 12:47:02 UTC

Antworten

Post by Bernd

Nicht nach jedem, nur bei unbeabsichtigten Abbruch.
Mit "systemctl stop restic-server" kann man den Service anhalten.

Wenn du meinst ... für mich liest sich das so (Siehe die Tabelle im
Link) das 'always' das Pgm. IMMER neu startet.

Du interpretierst das falsch.
"systemctl stop restic-server" stoppt IMMER den Service, ohne Autoneustart.

Marc Haber

2024-11-14 14:57:37 UTC

Antworten

Post by Bernd
Wenn du meinst ... für mich liest sich das so (Siehe die Tabelle im
Link) das 'always' das Pgm. IMMER neu startet.

So lange die Unit gestartet ist.

Arno Welzel

2024-11-13 14:44:13 UTC

Antworten

Post by Arno Welzel
[...]

Post by Ulli Horlacher
Aktuelles Beispiel: niemand konnte mir bisher sagen warum systemd einen
disabled Service beim booten ein dutzend mal starten will.

Weil "disabled" nur bedeutet "Service nicht direkt beim boot starten"
und nicht "Service niemals starten, auch dann nicht, wenn jemand das
explizit so haben will".

Und wer ist nun dieser "jemand"?

Andere Units etc. pe pe - eben alles, was den Service startet. Nur weil
er beim Boot nicht gestartet wird, bedeutet nicht, dass er nie gestartet
werden darf.

Post by Ulli Horlacher
Ich hab Server, die brauchen zum reboot 10 Minuten "dank" systemd.
Manchmal bleiben sie dabei auch stehen, dann hilft nur Reset.

Hatte ich auch schon mit SysV init.

Ich nicht und selbst wenn, waere es trivial das zu debuggen.
Bei systemd Haenger hab ich keine Loesung.

Und ich habe bei SysV init keine Lösung, wenn ein Init-Script extrem
lange braucht, ohne es aufwendig zu debuggen.

--
Arno Welzel
https://arnowelzel.de

Rupert Haselbeck

2024-11-13 13:20:06 UTC

Antworten

Post by Tim Ritberg
Du sagt es, systemd; nicht besser, nur anders :-D

In vielen Dingen ist es auch besser. Aber: All Software sucks.
Und Initscripte sucken mehr.

Die machen DEUTLICH weniger Problem UND sind viel besser zu verstehen und
zu debuggen.
Bei systemd ist das Meiste intransparent und vieles funktioniert schlecht
oder gar nicht. Debugging ist schwierig bis unmoeglich.
Aktuelles Beispiel: niemand konnte mir bisher sagen warum systemd einen
disabled Service beim booten ein dutzend mal starten will.
Ich hab Server, die brauchen zum reboot 10 Minuten "dank" systemd.
Manchmal bleiben sie dabei auch stehen, dann hilft nur Reset.

Bei derlei Klagen würde ein guter IT-Leiter spätestens beim zweiten Mal
mit einem freundlichen "Ich werde Sie mal zu einer Fortbildung zu diesem
Themenbereich anmelden (lassen). Sie haben da offenbar erhebliche Defizite"

MfG
Rupert

Marco Moock

2024-11-13 14:24:24 UTC

Antworten

Post by Tim Ritberg
Du sagt es, systemd; nicht besser, nur anders :-D

In vielen Dingen ist es auch besser. Aber: All Software sucks.
Und Initscripte sucken mehr.

Die machen DEUTLICH weniger Problem UND sind viel besser zu
verstehen und zu debuggen.
Bei systemd ist das Meiste intransparent und vieles funktioniert
schlecht oder gar nicht. Debugging ist schwierig bis unmoeglich.
Aktuelles Beispiel: niemand konnte mir bisher sagen warum systemd
einen disabled Service beim booten ein dutzend mal starten will.
Ich hab Server, die brauchen zum reboot 10 Minuten "dank" systemd.
Manchmal bleiben sie dabei auch stehen, dann hilft nur Reset.

Bei derlei Klagen würde ein guter IT-Leiter spätestens beim zweiten
Mal mit einem freundlichen "Ich werde Sie mal zu einer Fortbildung zu
diesem Themenbereich anmelden (lassen). Sie haben da offenbar
erhebliche Defizite"

Es steht dir frei, das Problem hier zu analysieren und dann uns
mitzuteilen, wie man sowas bei systemd angeht.

SysVinit ist in der Hinsicht tatsächlich trivialer.

--
Gruß
Marco

Spam und Werbung bitte an
***@nirvana.admins.ws

Marc Haber

2024-11-13 14:55:35 UTC

Antworten

Post by Marco Moock
SysVinit ist in der Hinsicht tatsächlich trivialer.

Aber dafür in drölf anderen Hinsichten aufwendiger und
fehlerträchtiger.

Grüße
Marc

Dietz Proepper

2024-11-13 21:57:04 UTC

Antworten

Post by Marco Moock
SysVinit ist in der Hinsicht tatsächlich trivialer.

Aber dafür in drölf anderen Hinsichten aufwendiger und
fehlerträchtiger.

Wann war nochmal die letzte größere Änderung der Semantik
$irgendwelchen systemd-Foos? Also "Änderung" wie in "nicht nur selber
geschriebene Units krachen"? Ist das länger als neun Monate her?

Sorry, aber systemd ist komplex, für die Komplexität miserabel
dokumentiert und war zumindest einen Großteil seiner Lebenszeit einfach
zu schnellen Änderungen unterworfen. Und man bekommt - natürlich -
Sachen, die auf Poettys Laptop nicht benötigt werden nur durch massive
Frickelei hin.

Achja. Habe ich das richtig mitgelesen, in einer der letzten Versionen
ist auch der SysVInit-Support rausgefallen?

--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled. - Richard P. Feynman, 1987

Marc Haber

2024-11-14 08:41:52 UTC

Antworten

Post by Marco Moock
SysVinit ist in der Hinsicht tatsächlich trivialer.

Aber dafür in drölf anderen Hinsichten aufwendiger und
fehlerträchtiger.

Wann war nochmal die letzte größere Änderung der Semantik
$irgendwelchen systemd-Foos? Also "Änderung" wie in "nicht nur selber
geschriebene Units krachen"? Ist das länger als neun Monate her?

Jahre.

Post by Dietz Proepper
Achja. Habe ich das richtig mitgelesen, in einer der letzten Versionen
ist auch der SysVInit-Support rausgefallen?

Das ist richtig. Das ist Mist.

Ich gehe aber davon aus dass man den sysv-generator dennoch wird
weiterverwenden können. Man wird ihn allerdings auch weiter pflegen
müssen.

Grüße
Marc

Dietz Proepper

2024-11-14 09:22:12 UTC

Antworten

Post by Marco Moock
SysVinit ist in der Hinsicht tatsächlich trivialer.

Aber dafür in drölf anderen Hinsichten aufwendiger und
fehlerträchtiger.

Wann war nochmal die letzte größere Änderung der Semantik
$irgendwelchen systemd-Foos? Also "Änderung" wie in "nicht nur selber
geschriebene Units krachen"? Ist das länger als neun Monate her?

Jahre.

Ok. 13 Monate ;-).

Post by Dietz Proepper
Achja. Habe ich das richtig mitgelesen, in einer der letzten
Versionen ist auch der SysVInit-Support rausgefallen?

Das ist richtig. Das ist Mist.

D.h. der letzte breaking change ist keine Jahre sondern Wochen her.
Mein Reden.

Post by Marc Haber
Ich gehe aber davon aus dass man den sysv-generator dennoch wird
weiterverwenden können. Man wird ihn allerdings auch weiter pflegen
müssen.

Ach, das wird dann übernächstes release vorsätzlich zerbrochen, mark my
words.

--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled. - Richard P. Feynman, 1987

Stefan Reuther

2024-11-13 16:57:50 UTC

Antworten

Post by Ulli Horlacher
Aktuelles Beispiel: niemand konnte mir bisher sagen warum systemd
einen disabled Service beim booten ein dutzend mal starten will.

[...]

Post by Rupert Haselbeck
Bei derlei Klagen würde ein guter IT-Leiter spätestens beim zweiten
Mal mit einem freundlichen "Ich werde Sie mal zu einer Fortbildung zu
diesem Themenbereich anmelden (lassen). Sie haben da offenbar
erhebliche Defizite"

Es steht dir frei, das Problem hier zu analysieren und dann uns
mitzuteilen, wie man sowas bei systemd angeht.
SysVinit ist in der Hinsicht tatsächlich trivialer.

SysV-init ist in der Hinsicht insofern trivialer, als dass es da den
Status "ein Service ist disabled" oder "ein Service kann als
Abhängigkeit gestartet werden" nicht gibt, also auch keine Problem in
dem Umfeld haben kann.

Genau wie ein Handkarren kein Problem mit der Einspritzpumpe haben kann.

(Ich würde zum Eingrenzen der Problems den Loglevel in
/etc/systemd/system.conf aufdrehen und evtl. mit systemd-analyze rumspielen.
Brute-Force-Methode: in die restic-server.service ein
"ExecStartPre=sleep 200" rein, dann erscheint es in `systemd-analyze
critical-chain`.)

Stefan

Ulli Horlacher

2024-11-13 17:54:34 UTC

Antworten

Post by Stefan Reuther
(Ich würde zum Eingrenzen der Problems den Loglevel in
/etc/systemd/system.conf aufdrehen

Da steht schon LogLevel=info

Post by Stefan Reuther
und evtl. mit systemd-analyze rumspielen.

Kommen wir zum naechsten Murks: systemd-analyze unit-files gibt
Binaermuell aus, der mein Terminal unbrauchbar macht.

Ich muss den output mit perl "saeubern", dann kommt raus:

ids: restic-server.service /etc/systemd/system/restic-server.service
ids: nfs-restic.mount /run/systemd/generator/nfs-restic.mount
ids: iscsi-san\x2dstore1-restic.mount /run/systemd/generator/iscsi-san\x2dstore1-restic.mount
aliases: restic-server.service restic-server.service
aliases: nfs-restic.mount nfs-restic.mount
aliases: iscsi-san\x2dstore1-restic.mount iscsi-san\x2dstore1-restic.mount

Das hilft mir aber auch nicht weiter, weil:

***@zoo:~# cat '/run/systemd/generator/iscsi-san\x2dstore1-restic.mount'
# Automatically generated by systemd-fstab-generator

[Unit]
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
SourcePath=/etc/fstab
After=***@dev-disk-by\x2dlabel-restic.target

[Mount]
Where=/iscsi/san-store1/restic
What=/dev/disk/by-label/restic
Type=ext4
Options=noauto

***@zoo:~# grep restic /etc/fstab
LABEL=restic /iscsi/san-store1/restic ext4 noauto 0 0
tik-nfs-test:/tik_nfs_test_restic /nfs/restic nfs nfsvers=3,rw,rsize=65536,wsize=65536,tcp,timeo=10,soft 0 0

Das sind nur mounts die eher zufaellig den string "restic" enthalten, das
hat erstmal nichts mir dem restic-server zu tun. Ich haette das auch
"Pflaumensturz" nennen koennen.

Ein filenamen mit \ zu erzeugen ist die naechste Stufe von bescheuert.

Post by Stefan Reuther
Brute-Force-Methode: in die restic-server.service ein
"ExecStartPre=sleep 200" rein, dann erscheint es in `systemd-analyze
critical-chain`.)

Dazu muss ich rebooten, geht erst spaeter.

Arno Welzel

2024-11-14 07:51:42 UTC

Antworten

Post by Stefan Reuther
(Ich würde zum Eingrenzen der Problems den Loglevel in
/etc/systemd/system.conf aufdrehen

Da steht schon LogLevel=info

Post by Stefan Reuther
und evtl. mit systemd-analyze rumspielen.

Kommen wir zum naechsten Murks: systemd-analyze unit-files gibt
Binaermuell aus, der mein Terminal unbrauchbar macht.

Passiert hier nicht.

--
Arno Welzel
https://arnowelzel.de

Marc Haber

2024-11-14 08:44:24 UTC

Antworten

Post by Stefan Reuther
und evtl. mit systemd-analyze rumspielen.

Kommen wir zum naechsten Murks: systemd-analyze unit-files gibt
Binaermuell aus, der mein Terminal unbrauchbar macht.

Bei mir funktioniert das einwandfre. Ich habe allerdings auch ein
aktuelles System mit einem aktuellen Desktop Environment. Schonmal mit
einem zum terminal passenden oder einfacheren TERM probiert?

Post by Ulli Horlacher
Ein filenamen mit \ zu erzeugen ist die naechste Stufe von bescheuert.

Ich finde das angemessen sinnvoll und üblich.

Post by Stefan Reuther
Brute-Force-Methode: in die restic-server.service ein
"ExecStartPre=sleep 200" rein, dann erscheint es in `systemd-analyze
critical-chain`.)

Dazu muss ich rebooten, geht erst spaeter.

Jeder hat ein Testsystem.

Grüße
Marc

Ulli Horlacher

2024-11-14 09:42:58 UTC

Antworten

Post by Stefan Reuther
und evtl. mit systemd-analyze rumspielen.

Kommen wir zum naechsten Murks: systemd-analyze unit-files gibt
Binaermuell aus, der mein Terminal unbrauchbar macht.

Bei mir funktioniert das einwandfre. Ich habe allerdings auch ein
aktuelles System mit einem aktuellen Desktop Environment. Schonmal mit
einem zum terminal passenden oder einfacheren TERM probiert?

TERM ist screen und das kann ich nur zu vt100 aendern, da passiert aber
dasselbe.
Ein Programm darf nicht einfach Binaerdaten ausgeben in der Annahme jeder
benutzt Gnome-term oder gar irgendwas mit wayland.
Ich administriere meine Server komplett ohne GUI.

Post by Ulli Horlacher
Ein filenamen mit \ zu erzeugen ist die naechste Stufe von bescheuert.

Ich finde das angemessen sinnvoll und üblich.

\ in Filenamen ueblich und sinnvoll??
Dann leben wir in voellig getrennten Welten.

Ralph Aichinger

2024-11-14 12:55:05 UTC

Antworten

Post by Ulli Horlacher
Ein Programm darf nicht einfach Binaerdaten ausgeben in der Annahme jeder
benutzt Gnome-term oder gar irgendwas mit wayland.
Ich administriere meine Server komplett ohne GUI.

Viele CLI und TUI-Programme wollen heute UTF-8-Unterstützung haben.

Und ich finde das eigentlich recht vernünftig.

/ralph -- ich hab noch ein echtes DEC VT220 am Dachboden, vielleicht
ich mal schauen ob das noch geht, und wie man sich damit bei
aktuellen CLI-Programmen tut

Ulli Horlacher

2024-11-14 13:06:01 UTC

Antworten

Post by Ulli Horlacher
Ein Programm darf nicht einfach Binaerdaten ausgeben in der Annahme jeder
benutzt Gnome-term oder gar irgendwas mit wayland.
Ich administriere meine Server komplett ohne GUI.

Viele CLI und TUI-Programme wollen heute UTF-8-Unterstützung haben.
Und ich finde das eigentlich recht vernünftig.

Das ist unvernuenftige Gaengelung.
Wozu gibts dann das locale System, wenns jeder nach belieben ignoriert?

Den Gedanken weitergefuehrt kann man genausogut sagen:

Viele Programme und Webseiten wollen heute Windows haben.
Und ich finde das eigentlich recht vernünftig.

Ralph Aichinger

2024-11-14 13:21:15 UTC

Antworten

Post by Ralph Aichinger
Viele CLI und TUI-Programme wollen heute UTF-8-Unterstützung haben.
Und ich finde das eigentlich recht vernünftig.

Das ist unvernuenftige Gaengelung.

Dass man Dinge, die enormen praktischen Sinn ergeben, und es seit 30(!)
Jahren gibt tatsächlich verwendet?

Post by Ulli Horlacher
Wozu gibts dann das locale System, wenns jeder nach belieben ignoriert?

Hä? Wer tut das? Nur kannst du halt mit oder ohne Locale-System einem
vt100 keine chinesischen Schriftzeichen o.ä. beibringen.

Post by Ulli Horlacher
Viele Programme und Webseiten wollen heute Windows haben.
Und ich finde das eigentlich recht vernünftig.

Wenn man davon absieht, dass das eine ein breit implementierter
offizieller Standard ist?

/ralph

Ulli Horlacher

2024-11-14 14:05:58 UTC

Antworten

Post by Ralph Aichinger
Viele CLI und TUI-Programme wollen heute UTF-8-Unterstützung haben.
Und ich finde das eigentlich recht vernünftig.

Das ist unvernuenftige Gaengelung.

Dass man Dinge, die enormen praktischen Sinn ergeben, und es seit 30(!)
Jahren gibt tatsächlich verwendet?

Ja, etwa so lange gibt es locale, das enorm praktisch ist.

Post by Ulli Horlacher
Wozu gibts dann das locale System, wenns jeder nach belieben ignoriert?

Hä? Wer tut das?

systemd, indem es Binaerzeichen ausgibt, die das gesetzte locale nicht
verarbeiten kann.

Post by Ralph Aichinger
Nur kannst du halt mit oder ohne Locale-System einem
vt100 keine chinesischen Schriftzeichen o.ä. beibringen.

Ich kenne kein Init-Subsystem, das zum Starten bzw Status-Abfrage mehr als
ASCII braucht.

Post by Ulli Horlacher
Viele Programme und Webseiten wollen heute Windows haben.
Und ich finde das eigentlich recht vernünftig.

Wenn man davon absieht, dass das eine ein breit implementierter
offizieller Standard ist?

Genau, wozu braucht es dann Linux?
Kann man doch ignorieren.

Marc Haber

2024-11-14 15:16:06 UTC

Antworten

Post by Ralph Aichinger
Viele CLI und TUI-Programme wollen heute UTF-8-Unterstützung haben.
Und ich finde das eigentlich recht vernünftig.

Das ist unvernuenftige Gaengelung.

Dass man Dinge, die enormen praktischen Sinn ergeben, und es seit 30(!)
Jahren gibt tatsächlich verwendet?

Ja, etwa so lange gibt es locale, das enorm praktisch ist.

Ich bin sehr froh darüber dass es inzwischen locales gibt, die
wirklich in allen Lebenslagen funktionieren. Ich habe neulich mal
wieder auf einem Kassendisplay den String "R{ckgeld" gesehen.

Mann was bin ich froh dass wir inzwischen endlich flächendeckend UTF-8
benutzen können. Ich sehe keinen Grund, 2024 noch auf diese
Errungenschaft zu verzichten. Es hat ja auch lange genug gedauert.

Post by Ulli Horlacher
systemd, indem es Binaerzeichen ausgibt, die das gesetzte locale nicht
verarbeiten kann.

Warum nutzt Du bewusst ein locale das heute nur noch von 0,01 %
Dinosaurieren verwendet wird? Warum machst Du es Dir bewusst so
schwer? Nur damit Du über systemd lästern kannst? Es gibt nun wirklich
genug Punkte an systemd, über die man sich zu Recht beschweren kann.
Aber um diese Punkte zu finden muss man sich erstmal darauf einlassen.

Post by Ralph Aichinger
Nur kannst du halt mit oder ohne Locale-System einem
vt100 keine chinesischen Schriftzeichen o.ä. beibringen.

Ich kenne kein Init-Subsystem, das zum Starten bzw Status-Abfrage mehr als
ASCII braucht.

Dass systemd auch in einem ASCII-only-locale Pfeile benutzt, halte ich
für einen Bug. Man wird Dich auslachen, wenn du den Bug einreichst.
Vermutlich nicht ganz zu unrecht.

Aber ja, eigentlich sollte Systemd => und <= verwenden wenn es
herausfindet dass das locale keine nativen Pfeile anzeigen kann.

Du weißt das nun und anstelle den trivialen workaround zu verwenden
frisst Du hier die Zeit von hunderten von Leuten um diese fruchtlose
Diskussion zu führen.

Ich kenne außer Dir niemanden, der sich fußaufstampfend freiwillig auf
ASCII only beschränkt in den 2020er Jahren. "Es hat vor 40 Jahren
gereicht" ist nicht wirklich eine ernstzunehmende Begründung dafür.

Grüße
Marc

Marc Haber

2024-11-14 15:10:22 UTC

Antworten

Post by Stefan Reuther
und evtl. mit systemd-analyze rumspielen.

Kommen wir zum naechsten Murks: systemd-analyze unit-files gibt
Binaermuell aus, der mein Terminal unbrauchbar macht.

Bei mir funktioniert das einwandfre. Ich habe allerdings auch ein
aktuelles System mit einem aktuellen Desktop Environment. Schonmal mit
einem zum terminal passenden oder einfacheren TERM probiert?

Ich habe jetzt wirklich versucht, systemd-analze unit-files dazu zu
bringen, mein Terminal kaputtzumachen. Ich habe es mit konsole und
xterm probiert, habe TERM auf vt100 gesetzt, das alles in screen
probiert, locale auf C gesetzt, es hat immer funktioniert.

Post by Ulli Horlacher
Ich administriere meine Server komplett ohne GUI.

Dito auf der Konsole eines (virtuellen) Servers. Ein Blech ohne GUI,
aber mit Monitor, habe ich hier leider nicht.

systemd-analyze unit-files gibt auch auf vt100 nach links und rechts
zeigende Pfeile aus. Das halte ich für einen Bug. Möchtest Du einen
einreichen?

Zusammengefasst schätze ich das so ein, dass Du Dir WIRKLICH Mühe
gibst, Deinen Arbeitsplatz so zu betreiben, dass er Basisanforderungen
heutiger Software schlicht nicht erfüllt. Zu arbeiten wie 1990, darauf
aber Software von 2024 einsetzen zu wollen, ist ein wenig unlogisch.

Post by Ulli Horlacher
Ein filenamen mit \ zu erzeugen ist die naechste Stufe von bescheuert.

Ich finde das angemessen sinnvoll und üblich.

\ in Filenamen ueblich und sinnvoll??
Dann leben wir in voellig getrennten Welten.

Ich lebe in der Welt von 2024.

systemd legt viel Informationen in Dateinamen, um sie nicht in der
Datei selbst schreiben zu müssen. Über diese Designentscheidung kann
man diskutieren, aber wenn man die Software nicht selbst geschrieben
hat, muss man akzeptieren was der Upstream sich hat einfallen lassen.
Das ist bei closed-source-software nur noch schlimmer.

Alleine dass sich jemand so viel Gedanken gemacht hat, nahezu
beliebige Strings in einen Dateinamen hineinzucodieren, und das auch
noch ausführlich zu dokumentieren wie in man systemd-unit(5), Kapitel
"String Escaping for Inclusion in Unit Names", zeigt mir dass sich da
jemand wirklich Gedanken gemacht hat und auch die Randfälle
berücksichtigt hat. Dass man nicht druckbare Zeichen in Strings mit
Backslash escaped, dürftest Du auch mit Deinem Wissensstand kennen. In
systemd wurde das halt in Dateinamen eingeführt und auf Zeichen
erweitert, die man in Dateinamen nicht haben möchte.

Du machst auf mich - leider erneut - den Eindruck, als wolltest Du
Dich nicht an die veränderte Welt anpassen. Du kannst da sicher hier
und vermutlich auch bei der Arbeit mit dem Fuß aufstampfen, aber die
Welt wird sich für Dich nicht zuück ändern. Mach entweder so bis zur
Rente weiter, oder lerne auf Deine alten Tage noch etwas. Es ist nicht
alles schlecht was anders ist als 1985.

Ich bin neulich von einem ehemaligen Kunden angerufen worden. "Wir
wollen jetzt mit IPv6 anfangen. Der Kollege, der das jetzt fünfzehn
Jahre lang blockiert hat, geht im Januar in Rente. Hast Du Zeit uns zu
helfen?"

Sei nicht dieser Kollege. Dafür bist Du zu gut.

Grüße
Marc

Dietz Proepper

2024-11-13 21:58:42 UTC

Antworten

Post by Stefan Reuther

Post by Ulli Horlacher
Aktuelles Beispiel: niemand konnte mir bisher sagen warum systemd
einen disabled Service beim booten ein dutzend mal starten will.

[...]

Post by Rupert Haselbeck
Bei derlei Klagen würde ein guter IT-Leiter spätestens beim zweiten
Mal mit einem freundlichen "Ich werde Sie mal zu einer Fortbildung
zu diesem Themenbereich anmelden (lassen). Sie haben da offenbar
erhebliche Defizite"

Es steht dir frei, das Problem hier zu analysieren und dann uns
mitzuteilen, wie man sowas bei systemd angeht.
SysVinit ist in der Hinsicht tatsächlich trivialer.

SysVInit ist vergleichsweise deterministisch, right.

--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled. - Richard P. Feynman, 1987

Marc Haber

2024-11-14 08:44:44 UTC

Antworten

Post by Stefan Reuther

Post by Ulli Horlacher
Aktuelles Beispiel: niemand konnte mir bisher sagen warum systemd
einen disabled Service beim booten ein dutzend mal starten will.

[...]

Post by Rupert Haselbeck
Bei derlei Klagen würde ein guter IT-Leiter spätestens beim zweiten
Mal mit einem freundlichen "Ich werde Sie mal zu einer Fortbildung
zu diesem Themenbereich anmelden (lassen). Sie haben da offenbar
erhebliche Defizite"

Es steht dir frei, das Problem hier zu analysieren und dann uns
mitzuteilen, wie man sowas bei systemd angeht.
SysVinit ist in der Hinsicht tatsächlich trivialer.

SysVInit ist vergleichsweise deterministisch, right.

Und macht hundertmal so viel Arbeit.

Grüße
Marc

Marco Moock

2024-11-13 14:22:17 UTC

Antworten

Post by Ulli Horlacher
Das ist doch MIST hoch drei!

Es ist nur anders.

Du sagt es, systemd; nicht besser, nur anders :-D

In vielen Dingen ist es auch besser. Aber: All Software sucks.
Und Initscripte sucken mehr.

Die machen DEUTLICH weniger Problem UND sind viel besser zu verstehen
und zu debuggen.

Slackware existiert. Bei mir läuft schon ein Rechner damit.

--
Gruß
Marco

Spam und Werbung bitte an
***@nirvana.admins.ws

Kay Martinen

2024-11-13 18:56:25 UTC

Antworten

Post by Ulli Horlacher
Das ist doch MIST hoch drei!

Es ist nur anders.

"nur" hoch drei!? ;)

Post by Tim Ritberg
Du sagt es, systemd; nicht besser, nur anders :-D

In vielen Dingen ist es auch besser. Aber: All Software sucks.

Ich dachte bisher; blauäugig vermutlich; das die Targets (Default vs.
graphic) ein einfacher Ersatz wären für ein Tellinit 3 (multiuser+net
ohne desktop) und tellinit 4 (voriges+Desktop) wären. Und man bei
ersterem dann auch eine textkonsole bekommt und irgendwie analog zu
'startX' den Desktop manuell starten könne - nur wenn man ihn bräuchte.

Aber da habe ich mich wohl auch geirrt (siehe nebenpost) also: all
Software sucks = Yes! (für 'systemd' Werte von $$Initsystem)

Bye/
/Kay

--
Posted via Leafnode

Marc Haber

2024-11-14 08:46:17 UTC

Antworten

Post by Kay Martinen
Ich dachte bisher; blauäugig vermutlich; das die Targets (Default vs.
graphic) ein einfacher Ersatz wären für ein Tellinit 3 (multiuser+net
ohne desktop) und tellinit 4 (voriges+Desktop) wären. Und man bei
ersterem dann auch eine textkonsole bekommt und irgendwie analog zu
'startX' den Desktop manuell starten könne - nur wenn man ihn bräuchte.

Schon Runlevel waren vorher von den Distributionen vorbesetzt im
Wesentlichen unbrauchbar weil viel zu granular. Deswegen hat man
logischerweise ein komplett anderes Konzept für systemd benutzt. Ich
habe das noch nicht so ganz kapiert was man alles damit machen kann.

Post by Kay Martinen
Aber da habe ich mich wohl auch geirrt (siehe nebenpost) also: all
Software sucks = Yes! (für 'systemd' Werte von $$Initsystem)

Man muss sich halt mit Dingen auseinandersetzen. Und ja, initsysteme
gelten als uncool, deswegen macht das niemand. Dabei ist ohne ein
anständes init alles nichts.

Grüße
Marc

Stefan+ (Stefan Froehlich)

2024-11-13 08:37:59 UTC

Antworten

Post by Ulli Horlacher
Das ist doch MIST hoch drei!

Es ist nur anders.

Es ist zu mächtig. Ich lese immer hier etwas, denke mir "ah, so
funktioniert das" und habe es ein paar Tage später wieder vergessen,
weil ich es zu selten brauche.

Bei jedem Anlassfall die systemd-Manpages zu studieren macht keinen
Spaß, zumal das vom Umfang her an die Literaturrecherche für eine
Bachelor-Arbeit erinnert.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Nur darben ist flauer als gerben! Stefan: Für Liebhaber!
(Sloganizer)

Tim Ritberg

2024-11-13 10:31:49 UTC

Antworten

Post by Ulli Horlacher
Das ist doch MIST hoch drei!

Es ist nur anders.

Es ist zu mächtig. Ich lese immer hier etwas, denke mir "ah, so
funktioniert das" und habe es ein paar Tage später wieder vergessen,
weil ich es zu selten brauche.
Bei jedem Anlassfall die systemd-Manpages zu studieren macht keinen
Spaß, zumal das vom Umfang her an die Literaturrecherche für eine
Bachelor-Arbeit erinnert.

Jop, systemd sucks.
Hab angefangen Devuan einzusetzen.

Tim

Arno Welzel

2024-11-13 14:49:14 UTC

Antworten

Post by Ulli Horlacher
Das ist doch MIST hoch drei!

Es ist nur anders.

Es ist zu mächtig. Ich lese immer hier etwas, denke mir "ah, so
funktioniert das" und habe es ein paar Tage später wieder vergessen,
weil ich es zu selten brauche.

Ist bei init-Scripts auch nicht anders - was man nur extrem selten
anfasst, vergisst man halt. Und wenn dann ein init-Script mal nicht
läuft, geht auch da die Sucherhei los, warum es beim Bootvorgang nicht
funktioniert, obwohl es im laufenden System problemlos benutzt werden kann.

Post by Stefan+ (Stefan Froehlich)
Bei jedem Anlassfall die systemd-Manpages zu studieren macht keinen
Spaß, zumal das vom Umfang her an die Literaturrecherche für eine
Bachelor-Arbeit erinnert.

Bei jedem Anlassfall das init-Script zu studieren und nachzuvollziehen,
warum es in Zeile x immer hängt, macht keinen Spaß.

--
Arno Welzel
https://arnowelzel.de

Stefan+ (Stefan Froehlich)

2024-11-13 19:57:10 UTC

Antworten

[systemd] ist zu mächtig. Ich lese immer hier etwas, denke mir
"ah, so funktioniert das" und habe es ein paar Tage später wieder
vergessen, weil ich es zu selten brauche.

Ist bei init-Scripts auch nicht anders - was man nur extrem selten
anfasst, vergisst man halt. Und wenn dann ein init-Script mal
nicht läuft, geht auch da die Sucherhei los, warum es beim
Bootvorgang nicht funktioniert, obwohl es im laufenden System
problemlos benutzt werden kann.

Ich war mit init-Skripts aus den gleichen Gründen (99,9% der Zeit
funktioniert alles ohnehin so, wie es soll) ähnlich schlecht
vertraut wie mit systemd - dennoch haben sie weit weniger genervt
und allfällige Probleme waren auch deutlich schneller behoben.

Dafür gibt's im Wesentlichen zwei Gründe:

a) die Skripts sind in einer Sprache geschrieben, die an vielen
Stellen eingesetzt wird und die ich daher (wenigstens leidlich)
beherrsche

b) die Skripte waren - zumindestens gefühlt - weit weniger mächtig,
weil man halt alles ausprogrammieren hätte müssen. Das ist natürlich
nicht nur ein Vorteil, beim Bugfixing allerdings sehr wohl

Bei jedem Anlassfall die systemd-Manpages zu studieren macht
keinen Spaß, zumal das vom Umfang her an die Literaturrecherche
für eine Bachelor-Arbeit erinnert.

Bei jedem Anlassfall das init-Script zu studieren und
nachzuvollziehen, warum es in Zeile x immer hängt, macht keinen
Spaß.

Aus Spaß mache ich derlei nie, umso besser ist es, wenn ich rasch
damit fertig bin. Systemd vermittelt mir immer das Gefühl, es gäbe
da so viel zu lernen, und ich sollte das doch endlich einmal tun.
Ist aber alles nur Illusion, es ist ja nicht abzusehen, dass ich das
jenseits des Bugfixings irgendwo brauchen könnte.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Das süße Geheimnis! Stefan, Trost in den Stunden des Zorns!
(Sloganizer)

Peter J. Holzer

2024-11-13 21:18:33 UTC

Antworten

[systemd] ist zu mächtig. Ich lese immer hier etwas, denke mir
"ah, so funktioniert das" und habe es ein paar Tage später wieder
vergessen, weil ich es zu selten brauche.

Ist bei init-Scripts auch nicht anders - was man nur extrem selten
anfasst, vergisst man halt. Und wenn dann ein init-Script mal
nicht läuft, geht auch da die Sucherhei los, warum es beim
Bootvorgang nicht funktioniert, obwohl es im laufenden System
problemlos benutzt werden kann.

Im Prinzip ja, aber sie rufen diverse (je nach Distribution
unterschiedliche) Shell-Funktionen auf, die wiederum (je nach
Distribution unterschiedliche) Binarys aufrufen. Was die machen, ist
nicht immer so klar. Wenn man nur eine Distribution hat, hat man das
recht bald herausgefunden. Bei zwei (in meinem Fall: Debian und RHEL)
geht das auch noch. Wenn es mehr werden oder noch Nicht-Linuxe
dazukommen (in meinem Fall: HP-UX), wird die Intuition langsam
unzuverlässig. Systemd standardisiert das Ganze wenigstens innerhalb der
Linux-Welt (HP-UX sind wir vor geraumer Zeit losgeworden. Haben wir
gebührend gefeiert).

Post by Stefan+ (Stefan Froehlich)
b) die Skripte waren - zumindestens gefühlt - weit weniger mächtig,
weil man halt alles ausprogrammieren hätte müssen. Das ist natürlich
nicht nur ein Vorteil, beim Bugfixing allerdings sehr wohl

Jein. Systemd ist zwar viel mächtiger, aber die Konfiguration ist halt
deklarativ und nicht prozedural. Das nimmt viel an sichtbarer
Komplexität raus. Und allein, dass man gefühlte 90% der
Dependency-Probleme mit Restart=always fixen kann, befriedigt den
Pragmatiker in mir enorm (der Monk in mir hingegen besteht darauf, dass
das ein /dirty hack/ sei, und man das gefälligst ordentlich zu beheben
habe).

Bei jedem Anlassfall die systemd-Manpages zu studieren macht
keinen Spaß, zumal das vom Umfang her an die Literaturrecherche
für eine Bachelor-Arbeit erinnert.

Bei jedem Anlassfall das init-Script zu studieren und
nachzuvollziehen, warum es in Zeile x immer hängt, macht keinen
Spaß.

Ich habe mich mittlerweile damit abgefunden, dass ich nicht alles wissen
kann. Solange ich die Lösung schneller finde als die Kollegen, kann ich
mir meinen Ruf als "allwissende Müllhalde" erhalten ;-).

Im Ernst: Ich kenne sicher nur einen kleinen Teil der Fähigkeiten von
Systemd. Es reicht aber, dass ich die üblichen Anforderungen hinbekomme,
und wenn eine neue Anforderung gibt (kürzlich zum Beispiel:
Docker-Images über Systemd starten), dann lese ich halt nach.

Post by Stefan+ (Stefan Froehlich)
Ist aber alles nur Illusion, es ist ja nicht abzusehen, dass ich das
jenseits des Bugfixings irgendwo brauchen könnte.

Du bist doch auch Software-Entwickler, oder? Kein Bedarf an
Service-Files für Deine eigene Software oder irgendwelche
Third-Party-SW, die Du brauchst?

hp

Stefan+ (Stefan Froehlich)

2024-11-14 08:46:36 UTC

Antworten

[systemd] ist zu mächtig. Ich lese immer hier etwas, denke mir
"ah, so funktioniert das" und habe es ein paar Tage später
wieder vergessen, weil ich es zu selten brauche.

Ist bei init-Scripts auch nicht anders - was man nur extrem
selten anfasst, vergisst man halt. Und wenn dann ein init-Script
mal nicht läuft, geht auch da die Sucherhei los, warum es beim
Bootvorgang nicht funktioniert, obwohl es im laufenden System
problemlos benutzt werden kann.

[...]

Post by Stefan+ (Stefan Froehlich)
a) die Skripts sind in einer Sprache geschrieben, die an vielen
Stellen eingesetzt wird und die ich daher (wenigstens leidlich)
beherrsche

Ein Init-Skript in seiner Gesamtheit und für alle möglichen
Edge-Cases zu durchschauen, kann natürlich beliebig komplex werden;
der Vorteil von systemd für die Softwareentwickler erschließt sich
da relativ unmittelbar.

Mir reicht Debugging: Wenn etwas nicht läuft, füge ich an plausiblen
Stellen so lange echos ein, bis mir klar ist, was passiert und
idealerweise wenig später, was eigentlich passieren sollte. Das geht
zügig und idR ohne tiefere Kenntnisse der Materie.

Post by Stefan+ (Stefan Froehlich)
b) die Skripte waren - zumindestens gefühlt - weit weniger
mächtig, weil man halt alles ausprogrammieren hätte müssen. Das
ist natürlich nicht nur ein Vorteil, beim Bugfixing allerdings
sehr wohl

Jein. Systemd ist zwar viel mächtiger, aber die Konfiguration ist
halt deklarativ und nicht prozedural. Das nimmt viel an sichtbarer
Komplexität raus.

...und bringt statt dessen die Komplexität unter der Motorhaube von
systemd hinein. Das sieht ohne Frage extrem elegant aus, und für
einfache Dinge ist es auch einfach - aber die funktionieren ja eh.
Sobald etwas falsch läuft, stehe ich allerdings erst einmal völlig
hilflos da.

Post by Peter J. Holzer
Und allein, dass man gefühlte 90% der Dependency-Probleme mit
Restart=always fixen kann, befriedigt den Pragmatiker in mir enorm
(der Monk in mir hingegen besteht darauf, dass das ein /dirty
hack/ sei, und man das gefälligst ordentlich zu beheben habe).

In den wenigen Fällen, wo ich so etwas gemacht habe, hat es sich
rückblickend als schwerer Fehler erwiesen (weil die Ursache des
Problems dadurch nicht behoben wird, und dieses auch noch andere,
besser versteckte Auswirkungen hatte). Ich habe inzwischen eine
ziemliche Allergie gegen "einfach neu starten, dann läuft es
wieder".

Post by Stefan+ (Stefan Froehlich)
Ist aber alles nur Illusion, es ist ja nicht abzusehen, dass ich das
jenseits des Bugfixings irgendwo brauchen könnte.

Du bist doch auch Software-Entwickler, oder? Kein Bedarf an
Service-Files für Deine eigene Software oder irgendwelche
Third-Party-SW, die Du brauchst?

Ich habe in meinem Leben bisher genau eine systemd-Unit geschrieben,
und zwar ein lsync-Service, das ein paar Verzeichnisse zwischen zwei
Rechnern synchronisiert und - im Fehlerfall - per Mail Alarm gibt.
Wobei, genau genommen sind das sogar zwei systemd-Units, weil für
den Alarm eine eigene erforderlich war, und es hat mich einen guten
Arbeitstag gekostet, das fehlerfrei hinzubekommen.

Wäre gut investierte Zeit gewesen, hätte ich in der Zwischenzeit die
Fallstricke nicht schon wieder vergessen (die Units sehen super
elegant und übersichtlich aus, gerade so, als wären sie die Arbeit
von 5 Minuten - nur stimmt das halt leider nicht).

Ansonsten brauche ich nichts dergleichen, nein. Datenbanken und
Webserver erledigt mir das System, was sonst noch nötig ist, läuft
über eine Hand voll cronjobs.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan, so üppig wie das Bier. Kosten ohnegleichen.
(Sloganizer)

Dietz Proepper

2024-11-13 22:02:28 UTC

Antworten

[systemd] ist zu mächtig. Ich lese immer hier etwas, denke mir
"ah, so funktioniert das" und habe es ein paar Tage später wieder
vergessen, weil ich es zu selten brauche.

Ist bei init-Scripts auch nicht anders - was man nur extrem selten
anfasst, vergisst man halt. Und wenn dann ein init-Script mal
nicht läuft, geht auch da die Sucherhei los, warum es beim
Bootvorgang nicht funktioniert, obwohl es im laufenden System
problemlos benutzt werden kann.

Und versuch' bei einer systemd-Unit mal, durch Einfügen einiger
debug-Statements auch während des Boots Logs zu schreiben. TL:DR: not
worky.

Post by Stefan+ (Stefan Froehlich)
a) die Skripts sind in einer Sprache geschrieben, die an vielen
Stellen eingesetzt wird und die ich daher (wenigstens leidlich)
beherrsche

Du darfst in Deinen Initskripten sogar einen /beliebigen/
Skriptinterpreter verwenden. Und noch viel besser - die Initskripte
müssen nichtmal Skripte sein.

--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled. - Richard P. Feynman, 1987

Marc Haber

2024-11-14 08:48:15 UTC

Antworten

Post by Dietz Proepper
Und versuch' bei einer systemd-Unit mal, durch Einfügen einiger
debug-Statements auch während des Boots Logs zu schreiben. TL:DR: not
worky.

Da es innerhalb einer systemd-unit keine Reihenfolge gibt, weil es
deklarativ ist, geht dieser Ansatz schon im Ansatz fehl.

Grüße
Marc

Dietz Proepper

2024-11-14 09:22:50 UTC

Antworten

Post by Dietz Proepper
Und versuch' bei einer systemd-Unit mal, durch Einfügen einiger
debug-Statements auch während des Boots Logs zu schreiben. TL:DR: not
worky.

Da es innerhalb einer systemd-unit keine Reihenfolge gibt, weil es
deklarativ ist, geht dieser Ansatz schon im Ansatz fehl.

Eben.

--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled. - Richard P. Feynman, 1987

Marc Haber

2024-11-14 09:44:23 UTC

Antworten

Post by Dietz Proepper
Und versuch' bei einer systemd-Unit mal, durch Einfügen einiger
debug-Statements auch während des Boots Logs zu schreiben. TL:DR: not
worky.

Da es innerhalb einer systemd-unit keine Reihenfolge gibt, weil es
deklarativ ist, geht dieser Ansatz schon im Ansatz fehl.

Eben.

Das ist ein Feature.

Dietz Proepper

2024-11-14 13:36:30 UTC

Antworten

Post by Dietz Proepper
Und versuch' bei einer systemd-Unit mal, durch Einfügen einiger
not worky.

Da es innerhalb einer systemd-unit keine Reihenfolge gibt, weil es
deklarativ ist, geht dieser Ansatz schon im Ansatz fehl.

Eben.

Das ist ein Feature.

Nein. Es wird als solches vermarktet. Aber egal, das Thema ist ad
nauseam durchdekliniert.

--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled. - Richard P. Feynman, 1987

Arno Welzel

2024-11-14 08:03:21 UTC

Antworten

[systemd] ist zu mächtig. Ich lese immer hier etwas, denke mir
"ah, so funktioniert das" und habe es ein paar Tage später wieder
vergessen, weil ich es zu selten brauche.

Ist bei init-Scripts auch nicht anders - was man nur extrem selten
anfasst, vergisst man halt. Und wenn dann ein init-Script mal
nicht läuft, geht auch da die Sucherhei los, warum es beim
Bootvorgang nicht funktioniert, obwohl es im laufenden System
problemlos benutzt werden kann.

Ich war mit init-Skripts aus den gleichen Gründen (99,9% der Zeit
funktioniert alles ohnehin so, wie es soll) ähnlich schlecht
vertraut wie mit systemd - dennoch haben sie weit weniger genervt
und allfällige Probleme waren auch deutlich schneller behoben.
a) die Skripts sind in einer Sprache geschrieben, die an vielen
Stellen eingesetzt wird und die ich daher (wenigstens leidlich)
beherrsche
b) die Skripte waren - zumindestens gefühlt - weit weniger mächtig,
weil man halt alles ausprogrammieren hätte müssen. Das ist natürlich
nicht nur ein Vorteil, beim Bugfixing allerdings sehr wohl

Die Scripte sind Shell-Scripte und damit genau das Gegenteil von
"weniger mächtig". Examplarisch ist das init-Script von Apache 2 nicht
weniger als 350 Zeilen lang und enthält so "wenig mächtige" Konstrukte
wie das hier am Anfang:

DESC="Apache httpd web server"
NAME=apache2
DAEMON=/usr/sbin/$NAME

SCRIPTNAME="${0##*/}"
SCRIPTNAME="${SCRIPTNAME##[KS][0-9][0-9]}"
if [ -n "$APACHE_CONFDIR" ] ; then
if [ "${APACHE_CONFDIR##/etc/apache2-}" != "${APACHE_CONFDIR}" ]
; then
DIR_SUFFIX="${APACHE_CONFDIR##/etc/apache2-}"
else
DIR_SUFFIX=
fi
elif [ "${SCRIPTNAME##apache2-}" != "$SCRIPTNAME" ] ; then
DIR_SUFFIX="-${SCRIPTNAME##apache2-}"
APACHE_CONFDIR=/etc/apache2$DIR_SUFFIX
else
DIR_SUFFIX=
APACHE_CONFDIR=/etc/apache2
fi
if [ -z "$APACHE_ENVVARS" ] ; then
APACHE_ENVVARS=$APACHE_CONFDIR/envvars
fi

Die übrigen mehr als 300 Zeilen des Scripts spare ich mir hier.

Systemd-Units sind nur dagegen nur Definitionsdateien. "Mächtig" ist
daran gar nichts, sondern nur eine Anweisung an Systemd, was er tun
soll. Und das ist immer identisch, da das Format und die möglichen
Optionen genau festgelegt sind. Im Fall von Apache 2 sind das 17 Zeilen,
die definieren, wie das Ding starten oder stoppen soll und wovon es
abhängig ist:

[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target
Documentation=https://httpd.apache.org/docs/2.4/

[Service]
Type=forking
Environment=APACHE_STARTED_BY_SYSTEMD=true
ExecStart=/usr/sbin/apachectl start
ExecStop=/usr/sbin/apachectl graceful-stop
ExecReload=/usr/sbin/apachectl graceful
KillMode=mixed
PrivateTmp=true
Restart=on-abort

[Install]
WantedBy=multi-user.target

--
Arno Welzel
https://arnowelzel.de

Marc Haber

2024-11-14 08:47:10 UTC

Antworten

Initscripte sind also besser weil man sie debuggen kann. Ich ziehe
etwas vor, was man nur noch in einem zwanzigstel der Fälle wirklich
debuggen muss.

Grüße
Marc

Stefan+ (Stefan Froehlich)

2024-11-14 12:17:33 UTC

Antworten

Initscripte sind also besser weil man sie debuggen kann. Ich ziehe
etwas vor, was man nur noch in einem zwanzigstel der Fälle
wirklich debuggen muss.

Da ich den Vorteil habe, dass in beiden Fällen die Maintainer der
Pakete den allergrößten Teil des Debuggings erledigen, bleiben mir
bei beiden Varianten nur sehr wenig Fälle übrig - gefühlt nicht in
sonderlich unterschiedlicher Größenordnung.

Ich sage ja auch nur, dass für *mich* systemd hauptsächlich
Nachteile bringt. Es gibt fraglos Rollen, bei denen das anders
aussieht.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan kommt und 2024 Jahre öde haben sich vollendet.
(Sloganizer)

Marc Haber

2024-11-14 15:19:46 UTC

Antworten

Initscripte sind also besser weil man sie debuggen kann. Ich ziehe
etwas vor, was man nur noch in einem zwanzigstel der Fälle
wirklich debuggen muss.

Ich bin der Maintainer von nicht nur einem dieser Pakete, und habe es
in 20 Jahren Dasein als Debian Developer nicht geschafft, alle meine
Initscripts auch nur auf einem ähnlichen Stand der verfügbaren
Technologie zu halten. Und ich bin gottfroh dass ich das nicht mehr
tun muss.

Meine systemd-Units kann ich im Wesentlichen mit "meld" auf dem Stand
halten. Eine triviale systemd-Unit hat zehn Zeilen und hat mehr
features als jedes Initscript das ich je geschrieben habe; mit 80
Zeilen systemd-Unit erreiche ich ein Securityniveau an von dem ich zu
sysvinit-Zeiten nicht einmal geträumt habe.

Post by Stefan+ (Stefan Froehlich)
Ich sage ja auch nur, dass für *mich* systemd hauptsächlich
Nachteile bringt.

Ich bin (bzw war) Administrator in Flotten mit vierstelliger Anzahl
Rechner und möchte gerne für das Protokoll erwähnen, dass systemd auch
mein Leben als Admin in etlichen Punkten verbessert und vereinfacht
hat.

Grüße
Marc

Lesen Sie weiter auf narkive:

Nicht verwandte, aber interessante Themen

gestartet 2014-09-12 16:01:29 UTC

Hinweise auf Orbitale?

Ändert sich die Chemie unter Hochspannung?

gestartet 2017-10-16 14:36:30 UTC

Wenn der menschliche Körper zu 60% aus Wasser besteht, warum können wir dann nicht mit unserem Körper Feuer löschen?

gestartet 2018-05-07 05:39:30 UTC