service/systemd gesprächiger machen

[MSfree]

Warum sollte systemd überhaupt für meine fehlende Sorgfalt verantwortlich sein oder mich überhaupt auf irgendwas hinweisen?

Systemd soll und kann nicht auf irgendwelche Fehler hinweisen. Systemd sollte aber die Ausgaben der Dienst, die es startet, auf die Konsole durchreichen, und genau das macht es nicht.

Ist es so schwer zu begreifen, daß ich und andere gerne unmittelbar den Feedback hätten, den die Dienste von sich aus sowieso ausgeben?

[TomL]

Das habe ich auch, wenn ich den Postgresql Server starte. Früher wurde der erfolgreiche Start kurz in der Konsole bekannt gegeben. Jetzt passiert nichts, aber der Server läuft und funktioniert. Finde ich nicht gut, ist aber wohl nicht zu ändern. Wahrscheinlich gibt es die Möglichkeit, Startscripte anzupassen, aber da laß ich mal lieber die Finger von.

Ich weiss jetzt nicht, wie der Server gestartet wird, deswegen nur i.ü.S..... funktioniert sowas nicht...?

Code: Alles auswählen

systemctl start postgresql;systemd status postgresql

Damit würde man eine umfassende Statusmeldung bekommen.

[TomL]

[Systemd sollte aber die Ausgaben der Dienst, die es startet, auf die Konsole durchreichen, und genau das macht es nicht. Ist es so schwer zu begreifen, daß ich und andere gerne unmittelbar den Feedback hätten, den die Dienste von sich aus sowieso ausgeben?

systemd startet primär Dienste beim Boot, da gibts noch keine Konsole.... was ist daran schwer zu begreifen? Und wenn ich das dort einstelle, weiss ich, dass ich keine direkte Ausgabe mehr brauche, weils funktioniert.

Und außerdem kann ich mir doch jederzeit kurzerhand ein ServiceUnitStart.sh (oder kürzer benannt) stricken, welches "start" und "status" auf der Konsole direkt nacheinander ausführt. Dann habe ich doch die entsprechenden Ausgaben. Wo ist denn da das Problem?

[MSfree]

systemd startet primär Dienste beim Boot, da gibts noch keine Konsole.... was ist daran schwer zu begreifen?

Falsch, die Konsole ist bereits beim Booten vorhanden.

Systemd ist dazu gedacht, Dienste zu verwalten, also zu stoppen, zu starten und zu (de)aktivieren. Dazu gehört auch, daß man manuell wärend des Betriebs eingreift.

Und außerdem kann ich mir doch jederzeit kurzerhand ein ServiceUnitStart.sh....

Thema verfehlt, 6

Das simulilert nicht, wie sich der Dienst verhält, wenn er von Systemd gestartet wird.

[TomL]

Falsch, die Konsole ist bereits beim Booten vorhanden.

Also mal ehrlich, auf die Idee, irgendwelchen Services mitzugeben, auf welcher Konsole sie beim Boot und beim Start des Service schreiben, die ich beim Booten ja erstmal sowieso nicht sehe,, sondern nur die durchrauschenden Massenmeldungen, würde ich nicht kommen.Gut, wenn das jemand braucht, würde ich ein Startsystem empfehlen, was das unterstützt. Vielleicht kann systemd das ja auch... ich kann mir jedenfalls kein Szenario vorstellen, wo das für mich sinnvoll wäre.... aber ich bin ja auch nur Laie.

Systemd ist dazu gedacht, Dienste zu verwalten, also zu stoppen, zu starten und zu (de)aktivieren. Dazu gehört auch, daß man manuell wärend des Betriebs eingreift.

Ja und? Ich erkenne das Problem an der Stelle nicht.

Das simulilert nicht, wie sich der Dienst verhält, wenn er von Systemd gestartet wird.

Kannst Du mir den Unterschied erklären, der besteht, wenn ich systemd den Dienst via systemctl manuell starten lasse oder via "enabled" während des Boots? Der imho einzige Unterschied sind die Abhängigkeiten, aber die Kontinuität oder auch Kontiguität dieser Abhängigkeiten sind doch sowieso nicht im manuellen Start zu verifizieren, weil das ein völlig anderer Background ist als während des Bootens. Und das als Manko systemd anzulasten, wo der gesamte Systemstart dynamisch und durchaus flexibel interpretiert abläuft, geht ja wohl gar nicht. Um die genannten Abhängigkeiten zu prüfen, brauch ich 'den' Job (das hatte ich weiter oben schon gesagt) jedenfalls nicht. Das teste ich mit einer Service-Unit und einem extra dafür ausgestatteten Debug-Job, der mir genau an diesem Punk Eindeutigkeit verschafft.

Aber ist auch nicht so wichtig.... wir haben anscheinend grundverschiedene Ansichten darüber, was systemd leistet, nicht leistet oder gar zu leisten hat. Ich jedenfalls will nicht, dass es die Dinge anders handhabt, als es das jetzt tut. Ich halte das genau so für perfekt.

[scientific]

Bei manchen Daemons meckert systemctl sehr wohl, wenn die Konfiguration fehlerhaft ist.
Ich glaub, mpd ist so ein Daemon. Wenn ich Mist in die /etc/mpd.conf schreibe, dann bemerkt das systemctl, wenn mpd nicht korrekt gestartet werden kann, und weist mich darauf hin.
Ich hab bei wichtigen Dämonen sogar eine Mailbenachrichtigung eingerichtet, wenn der Start fehlschlägt...
OnFailure=...

Ich denke auch, dass die Erwartungshaltung an systemd zu hoch ist. Vielleicht ist sie bei manchen sogar deshalb so hochgeschraubt, damit es ganz sicher wieder einen Grund gibt, um auf systemd schimpfen zu können.

lg scientific

[TomL]

@msfree

Thema verfehlt, 6

Manchmal muss ich einfach erst mal ne Runde mit meinem Hund spazierengehen und währenddessen darüber nachdenken, ob ich nicht vielleicht doch unrecht haben könnte. Das ist ja wirklich nicht auszuschließen. Um mir darüber also selber Klarheit zu verschaffen, möchte ich dir zwei einfache Fragen stellen.

Stell dir das folgende hoch-komplizierte Szenario vor.... die drei Jobs A, B und C sollen gestartet werden. Dabei muss B nach A gestartet werden, und zwingend vor C. Also nix besonderes, leicht nachzuvollziehen.

Nun kann ich mir 3 Service-Units schreiben und diese 3 Unit in gewünschter Reihenfolge manuell via systemctl starten. Ich kann mir aber genauso gut auch die ExecStart-Statements aus den Units nehmen und die Binaries damit einfach direkt starten. Beides funktioniert, beides muss im Endergebnis aufs gleiche rauskommen, und zwar das die drei Jobs erfolgreich ihre Arbeit verrichten. Und nun die erste Frage an Dich:

Was hat systemd bei genau diesem Ablauf mit dem erfolgreichen Start dieser 3 Jobs zu tun, in welcher Verantwortung ist es dabei? Mein Anwort ist: a=überhaupt nichts, b=überhaupt keine. Das wird umso deutlicher, wenn ich -wie angedeutet- die Binaries direkt starte.... obwohl es hier völlig egal ist, ob ich das via Unit oder direkt tue. Gibt es Fehler in der Job.conf oder beim Start, sehe ich die hier und ich muss sie korrigieren. Aber dafür brauch ich doch kein systemd.... und den zuvor hergestellten Zusammenhang zu systemd verstehe ich überhaupt nicht.

Wenn ich nun diese 3 Jobs nicht mehr manuell starten will, sondern beim systemstart, dann trage ich kurzerhand in die Unit des Jobs 'B' die beiden Statements "after a und before c" ein und hänge alle 3 an das passende Target oder, wie ich das bei netzwerkrelevanten Jobs tue, in Abhängigkeit nach meiner Unit "network_wait_online". Und jetzt die zweite Frage an Dich:

Wo ist hier der Unterschied zu meinen obigen manuellen Starts via systemctl oder zum direkten Start der Binaries? Was ist hier anders, dass man jetzt hier zusätzlich irgendwas weiteres kontrollieren, ausgeben oder sonstwas anstellen muss, um zu sehen, ob es läuft. Ich sage, man braucht keine Streichhölzer, um eines anzuzünden, nur um dann über die Position des Lichtschalters zu sehen, dass das Licht aus ist.

Um festzustellen, dass Jobs ordentlich eingestellt sind, brauch ich kein systemd. Und wenn sie ordentlich eingestellt sind, laufen die mit oder ohne systemd. systemd muss den Kram doch nur starten.... sonst nix.

Ich denke auch, dass die Erwartungshaltung an systemd zu hoch ist.

Genau das denke ich auch. systemd ist doch wirklich nix anderes als ein quasi-cleverer Scheduler zum Starten irgendwelcher Jobs. Und das macht es parallelisiert, dynamisch und flexibel interpretiert richtig toll. Dann ist es noch ein bissken Buchhalter, indem es die Jobs vernünftig verwaltet, damit auch der Shutdown in umgekehrter Reihenfolge ordnungsgemäß ablaufen kann. Und es bietet mir darüber hinaus noch viele weitere gute Gimmicks, die mir das Arbeiten erleichtern. Ich denke auch, dass systemd völlig unberechtigt eine viel zu große Bedeutung beigemessen wird, und das -hier m.E. total unpassend- Sachverhalte durcheinander geworfen werden.

[mat6937]

Bei manchen Daemons meckert systemctl sehr wohl, wenn die Konfiguration fehlerhaft ist.

Oder auch wenn das /etc/init.d/<script> für systemd nicht geeignet ist, aber vom maintainer trotzdem unverändert übernommen wird. Z. B.:

Code: Alles auswählen

systemctl restart ircd-irc2.service
Job for ircd-irc2.service failed. See 'systemctl status ircd-irc2.service' and 'journalctl -xn' for details.

[TomL]

systemctl restart ircd-irc2.service
Job for ircd-irc2.service failed. See 'systemctl status ircd-irc2.service' and 'journalctl -xn' for details.
[/code]

Das passiert u.a. dann, wenn die Unit im Vordergrund gestartet wurde und der Process mit "ungleich 0" endet. Beim Start durch "enabled" landet der Eintrag im Journal. Das kann man einfach testen:

Code: Alles auswählen

nano /usr/local/bin/test

Code: Alles auswählen

#! /bin/bash
exit 1

Code: Alles auswählen

nano /etc/systemd/system/test.service

Code: Alles auswählen

[Unit]
Description=Test

[Service]
Type=oneshot
ExecStart=/usr/local/test

[Install]
WantedBy=multi-user.target

Code: Alles auswählen

systemctl start test
Job for test.service failed because the control process exited with error code.
See "systemctl status test.service" and "journalctl -xe" for details.

[mat6937]

..., wenn die Unit im Vordergrund gestartet wurde

Ja, aber in meinem Beispiel gibt es ja keine klassische Unit. Es wird "/etc/init.d/ircd-irc2" von systemctl verwendet.

Code: Alles auswählen

:~ $ systemctl status ircd-irc2
● ircd-irc2.service - LSB: Starts/stops the irc daemon
   Loaded: loaded (/etc/init.d/ircd-irc2)
   Active: activating (start) since Thu 2017-02-09 19:24:31 CET; 1min 11s ago
  Process: 2256 ExecStop=/etc/init.d/ircd-irc2 stop (code=exited, status=0/SUCCESS)
  Control: 2260 (ircd-irc2)
   CGroup: /system.slice/ircd-irc2.service
           ├─2260 /bin/sh /etc/init.d/ircd-irc2 start
           └─2262 /usr/sbin/ircd

[TomL]

Ja, aber in meinem Beispiel gibt es ja keine klassische Unit. Es wird "/etc/init.d/ircd-irc2" von systemctl verwendet.

Was passiert, wenn der Prozess gestartet ist und du gibst im CLI folgendes ein:

Code: Alles auswählen

systemctl cat ircd-irc2

[mat6937]

... du gibst im CLI folgendes ein:

Code: Alles auswählen

systemctl cat ircd-irc2

Das ist die Ausgabe:

Code: Alles auswählen

:~ $ systemctl cat ircd-irc2
# /run/systemd/generator.late/ircd-irc2.service
# Automatically generated by systemd-sysv-generator

[Unit]
SourcePath=/etc/init.d/ircd-irc2
Description=LSB: Starts/stops the irc daemon
Before=runlevel2.target runlevel3.target runlevel4.target runlevel5.target
After=network-online.target remote-fs.target all.target
Wants=network-online.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SysVStartPriority=4
ExecStart=/etc/init.d/ircd-irc2 start
ExecStop=/etc/init.d/ircd-irc2 stop

[TomL]

Sieht nicht nach klassischer Unit aus... oder vielleicht doch?

[mat6937]

... oder vielleicht doch?

Mit "/etc/init.d/ircd-irc2" nicht. Aber ich werde eine schreiben, ... ohne "/etc/init.d/ircd-irc2".

[TomL]

... oder vielleicht doch?

Mit "/etc/init.d/ircd-irc2" nicht. Aber ich werde eine schreiben, ... ohne "/etc/init.d/ircd-irc2".

Das wird möglicherweise nicht funktionieren. Fakt ist, systemd startet einen wrapper statt des eigentlichen Daemons, und zwar hier das init.d-script. Du müsstest also den echten Aufruf aus dem Script rauslesen, und dann kannst Du einfach direkt eine Unit verwenden. Alternativ kannst Du natürlich auch den Wrapper behalten, den sysvinit/runlevel-Kram im Header entfernen und ein normales Bash-Script daraus basteln. Und diesen "neuen" Wrapper kannst Du dann prima via Unit einstellen... allerdings bist Du dann dafür verantwortlich festzulegen, welches Target das richtig ist.

[scientific]

Nachem bei mir so mancher Dienst mit einer Unit, die sich auf ein init-Skript bezieht, Probleme machte, hab ich diese Skripte dann analysiert und selber Units dafür geschrieben.
Das klappt auch ganz gut.

Mancher Dienst hat ewig viel Code, der Prüft, ob die Kiste am Stromnetz hängt, oder am Akku. Speziell Dienste, die per cron aufgerufen werden.
Das löst systemd in einer Zeile.

Oder ich hab mir ein dispatcherskript für nm geschrieben, welches network-online.target stoppt und startet, in abhängigkeit, ob es eine aktive Verbindung zum Netz gibt. Dann hab ich selber Dienste an dieses Target gehängt (fetchmail und fetchnews z. B.) welche dann nur laufen, wenn die Kiste tatsächlich online ist.
Sind pro unit bloß eine Zeile mehr
BindsTo=network-online.target,bzw PartOf=network-online.target

[MoonKid]

Mal wieder spannend (und durchaus lehrreich!) wie solche IMO simplen Fragen hier ausarten.

Als Laie klinke ich mich mal ein und möchte auf einige Argumente/Aspekte hier eingehen:

Ich hab mir die mapage und config von systemd nochmal genauer angeschaut - insbesondere bezüglich Ausgaben- und Log-Funkionalität. Ehrlich gesagt, habe ich das nicht wirklich verstanden, weil die Einstellungsmöglichkeiten diesbezüglich sehr komplex sind. Allerdings schließe ich daraus, dass sich systemd daher durchaus den "Meldungen" seiner Units/Deamons anehmen kann/will und diese auch umleiten zu können scheint. Aktuell kann man daher systemd durchaus eine Verantwortlichkeit bezüglich gewisser Meldungen seiner Units (und dahinterliegender Deamons) zusprechen - unabhängig davon ob das konzeptionell nun sinnvoll ist oder nicht.

Vermutlich ist es aufgrund dieser komplexen Einstellungsmöglichkeiten auch zu erklären, warum bei manchen Units Output kommt und bei anderen nicht.

Da es keine simple (für mich verständliche) Option gibt, um systemd zu entsprechenden Output zu bringen, lasse ich die Finger davon und werde mit dem aktuellen Zustand einfach erst mal leben und eben ggf. explizit nachprüfen.

Die Notwendigkeit solcher Nachprüfungen (ob ein Deamon nun läuft oder nicht) ergibt sich insbesondere (wie jemand schon anmerkte) 1. aus der Seltenheit solcher Aktionen und 2. aus der Unerfahrenheit und dem mangelnden Einblick/Verständnis ins Gesamtsystem eines Users wie mir. Der DAU sitzt an der Tastatur und das bin ich - soviel hab ich gelernt.
Nebenbei vermute ich (als Laie) auch, dass es durchaus Situationen gibt, in dennen sich das Environment eines Deamons signifikant unterscheidet zwischen einem Start als service (z.B. service minidlna start) und einem lokalen Start (z.B. minidlna -u minidlna). Anders ausgedrückt: Ich vertraue nicht darauf, dass ein explizit gestarteter, gut konfigurierter und funktonierender Deamon, ebenso gut funktioniert, wenn er beim Booten mit systemd gestartet wird.

[TomL]

Nebenbei vermute ich (als Laie) auch, dass es durchaus Situationen gibt, in dennen sich das Environment eines Deamons signifikant unterscheidet zwischen einem Start als service (z.B. service minidlna start) und einem lokalen Start (z.B. minidlna -u minidlna).

Wo sollen denn die für den Daemon relevanten Unterschiede herkommen, wer zeichnet dafür verantwortlich? Natürlich gibt es Unterschiede, und zwar fehlen bei einem Start über Service-Unit die obligatorischen User-Vars und X11-Vars im Environment... die sind beim Start im Terminal natürlich gesetzt, aber die sind bei einem Daemon irrelevant, da der Job sowieso mit root-Rechte und ohne Display läuft.

Teste doch einfach selber, wie sich das Environment unterscheidet, mit zwei einfachen "Aufrufen":
Einmal direkt als root im Terminal

Code: Alles auswählen

/bin/bash -c "/usr/bin/env >/root/lsenv1"

und einmal via service-unit

Code: Alles auswählen

/bin/bash -c "/usr/bin/env >/root/lsenv2"

Und dann vergleich die Ergebnisse, und du siehst, dass seitens systemd nichts spezifisches und für den Job-Lauf relevantes gesetzt wurde. Man sollte das imho besser überprüfen, anstatt sich von Aberglauben leiten zu lassen.

Und wenn Deine beiden Beispielaufrufe absolut identisch sind, also das auch exakt genau "minidlna -u minidlna" im Exec-Start-Statement steht, wo sollen denn da die Unterschiede herkommen? Man darf bei einem solchen Vergleich natürlich nicht den Fehler machen, die service-unit als root zu starten und den Terminalbefehl als User. Dieser Vergleich ergibt Mist. Und natürlich muss man überprüfen, ob die Service-Unit selber explizit Umgebungs-Vars setzt.... aber wenn ich das zuvor auch beim Terminalstart tue, sehe ich auch da keinen Unterschied.

Anders ausgedrückt: Ich vertraue nicht darauf, dass ein explizit gestarteter, gut konfigurierter und funktonierender Deamon, ebenso gut funktioniert, wenn er beim Booten mit systemd gestartet wird.

Die Aussage hat für mich die gleiche Überzeugungswirkung, als wenn mich jemand von Horoskopen überzeugen wolllte. Und Horoskope halte ich nun wirklich für den absoluten Unfug. Zumal systemd überhaupt nichts mit dem "gut konfiguriert" zu tun hat. Die Konfiguration ist für den Daemon, nicht für systemd, vermutlich weiss der Daemon nicht mal den Unterschied, wenn er von systemd oder manuell gestartet wurde. Wieso sollte sich ein Programm anders verhalten, nur weil es von systemd gestartet wurde, im Vergleich zum identischen Aufruf via Terminal? Das ist mir echt zu hoch. Dafür würde ich zu gerne Mal ein Beispiel sehen und gegenprüfen.

[MoonKid]

Du hast den Kern meiner Aussage nicht verstanden.

Ich vertraue dem System nicht, weil ich ihm mißtraue, sondern weil mir selber das tiefere Verständnis des Systems und die Erfahrung damit fehlt. Ich bin der DAU! Und ich kann nicht jedes Detail immer irgendwo nachlesen. Das kann ich mal mchen, wenn ich Langeweile habe und mir ein System from scratch zusammenbaue. Danach vertraue ich auf solche Sachen.

Fakt ist (wie du selbst bestätigst) die Environments unterscheiden sich. Dabei ist aus meiner Erfahrung, statistisch gesehen und chaostheoretisch gesehen, absolut irrelevant, worin diese Unterschiede bestehen.

Nochmal: Der relevante Unterschied hier in der Argumentation ist, dass du der allwissende erfahrende Admin bist und ich nur der "erfahrene" DAU. In meiner Position (Unwissenheit) ist es gesünder, immer mit dem Schlimmste zu rechnen und möglichst alles anzuzweifeln und zu überprüfen. Nebenbei bin ich übrigens auch noch Wissenschaftler - vielleicht kommt meine Haltung auch daher.