service/systemd gesprächiger machen

[MoonKid]

Hab hier Debian unstable. Wenn ich sudo service meindeinst start|restart|stop usw mache, bekomme ich nie eine Meldung (auf stdout oder stderr, Log-Files sind hier nicht gemeint). Keine Erfolgsmeldugn, Fehler oder ähnliches. Ich muss es immer explizit überprüfen, ob der Dienst jetzt tatsächlich das getan hat, was ich wollte.

Lässt sich das ändern?

Unter Ubuntu Trusty und auch einem propritären QNAP NAS ist das anders.

[TomL]

Ich muss es immer explizit überprüfen, ob der Dienst jetzt tatsächlich das getan hat, was ich wollte.

Wie oft passiert es, dass der Dienst nicht korrekt gestartet wurde?

[MSfree]

Wie oft passiert es, dass der Dienst nicht korrekt gestartet wurde?

Was hat das mit der ursprünglichen Frage zu tun?

Mich ärgert das auch. Vor allem, wenn man noch in der Konfigurationsphase ist, wäre es schon hilfreich, sofort zu erfahren, ob der Dienst sauber gesaterte wurde oder der sich wegen eines Fehlers in der Konfiguration gleich wieder beendet hat.

[schwedenmann]

Hallo


Kann ev. an der system.conf in /etc/systemd liegen.

Dort sind quasi alle Optionen nicht auskomemntiert, systemd tut quasi nichts preiszugeben, schient die Standardvoreinstellung bei Debian zu sein, müßte man dann mal mit Ubuntu vergleichen.

mfg
schwedenmann

[TomL]

Was hat das mit der ursprünglichen Frage zu tun?

Das hat in sofern mit der Frage zu tun, dass ich in Frage stelle, das -ich zitiere- "Ich muss es immer explizit überprüfen" überhaupt notwendig ist. Der Job an sich hat imho erst mal gar nix mit einer Service-Unit zu tun. Das heisst, der läuft im Regelfall auch ohne Service-Unit. Und erst dann, wenn der Job das tut, was ich von ihm erwarte, dann starte ich ihn via service-unit.... aber dann habe ich doch keine Zweifel mehr daran, dass er nicht "failed". Genau vor dem Aspekt ist die Service-Unit nämlich nur sekundär wichtig, ich sichere vorher auf Seiten des Jobs ab, dass er tut, was er soll.

Und andersrum, wenn ich mit dem Prinzip "Service-Unit" experimentiere, dann mach ich das nicht mit einem Produktiv-Job, sondern mit irgendwas harmlosen, unwichtigen, was nix kaputt machen kann.Und dabei ist der Job nur sekundär wichtig. Da gilt mein Augenmerk der Service-Unit.

Im Fazit zweifel ich eben an, dass man das regelmäßig kontrollieren muss. Und meine Frage versucht sich von hinten anzunähern und herauszufinden, wo die Probleme liegen.... entweder falsche Serve-Unit oder fehlerhafter Job.... das sind imho zwei getrennte Aspekte. Was falsch ist, muss korrigiert werden, aber ein "immer prüfen" ist definitiv nicht notwendig.

[TomL]

Dort sind quasi alle Optionen nicht auskomemntiert, systemd tut quasi nichts preiszugeben, schient die Standardvoreinstellung bei Debian zu sein, müßte man dann mal mit Ubuntu vergleichen.

In meiner an der Stelle unveränderten Standard-Stretch-Installation steht beispielsweise zu meiner Service-Unit folgendes im Log:

Code: Alles auswählen

journalctl -b | grep network_wait_online
Feb 08 10:42:41 thomaspc systemd[1]: Starting thlu:network_wait_online.service:   Waiting for Network or Server to be up...
Feb 08 10:42:41 thomaspc thlu:network_wait_online[1787]: active/running   Server=10.10.1.2
Feb 08 10:42:44 thomaspc thlu:network_wait_online[2363]: Host 10.10.1.2 is reachable! (RC:0, after 3 Seconds wait)
Feb 08 10:42:44 thomaspc thlu:network_wait_online[2366]: Successful terminated with exitcode=0
Feb 08 10:42:44 thomaspc systemd[1]: Started thlu:network_wait_online.service:   Waiting for Network or Server to be up.

Sowohl systemd erzählt vom erfolgreichen Start, der Job selber quasselt auch. Das war in Jessie aber auch schon so.

[scientific]

Ich hab für solche Testphasen immer ein zweites Terminal offen, in dem journalctl -f läuft.

[TomL]

Ich auch!

[sbruder]

Mal ein Vergleich zwischen init.d-Kompatibilitätsmodus, ›service‹-Restart und systemctl:

Code: Alles auswählen

# /etc/init.d/apache2 restart                                                                                                                                           :(
[ ok ] Restarting apache2 (via systemctl): apache2.service.
# systemctl restart apache2
# service apache2 restart
# 

der Init.d-Kompaibillitätsmodus gibt also etwas zurück, der Rest nicht.
Wenn ich aber einen Fehler in der apache2-Konfigdatei habe, bekomme ich mit allen drei einen Fehler:

Code: Alles auswählen

Job for apache2.service failed. See 'systemctl status apache2.service' and 'journalctl -xn' for details.

Ich habe das mit anderen Diensten nicht ausprobiert, eventuell liefern die an systemd schon ein »OK, bin gestartet« und erst danach merken sie, dass etwas schief gelaufen ist?

[TomL]

Ich habe das mit anderen Diensten nicht ausprobiert, eventuell liefern die an systemd schon ein »OK, bin gestartet« und erst danach merken sie, dass etwas schief gelaufen ist?

Ja, das kann passieren, wenn sich der Dienst "fork'ed" und der Parent-Prozess nicht darauf wartet, ob der Fork auch wirklich erfolreich läuft, sondern einfach direkt nach dem 'fork' sagt "Ok, bin fertig, ich habe alles getan und beende mich mit exit 0".

Systemd sieht nur den Return-Code 0 und betrachtet den Prozess als erfolgreich gestartet. Das heisst, der Parentprozess, welcher den Daemon fork'ed ist nicht sauber programmiert. Dabei wäre es richtig, wenn der Parentprozess prüft, ob sein Fork überhaupt läuft und mit exit 1 bzw. ungleich 0 zurückkehrt, wenn nicht.

[scientific]

Ich habe das mit anderen Diensten nicht ausprobiert, eventuell liefern die an systemd schon ein »OK, bin gestartet« und erst danach merken sie, dass etwas schief gelaufen ist?

Ja, das kann passieren, wenn sich der Dienst "fork'ed" und der Parent-Prozess nicht darauf wartet, ob der Fork auch wirklich erfolreich läuft, sondern einfach direkt nach dem 'fork' sagt "Ok, bin fertig, ich habe alles getan und beende mich mit exit 0".

Systemd sieht nur den Return-Code 0 und betrachtet den Prozess als erfolgreich gestartet. Das heisst, der Parentprozess, welcher den Daemon fork'ed ist nicht sauber programmiert. Dabei wäre es richtig, wenn der Parentprozess prüft, ob sein Fork überhaupt läuft und mit exit 1 bzw. ungleich 0 zurückkehrt, wenn nicht.

Das hört sich ganz nach dem an, was Pöttering immer wieder kritisiert, und was ihm als Arroganz vorgeworfen wird: "... der Daemon ist falsch programmiert. Wir machen das richtig..."

Sehe ich das richtig?

lg scientific

[TomL]

"... der Daemon ist falsch programmiert. Wir machen das richtig..."

Ob man das wirklich so 'reduziert' resümieren kann... hmmm... ich glaube eher nicht. Meiner Meinung nach besteht dieser "Tatbestand" nicht erst seit Systemd, hinsichtlich sauberen Code galt das doch eigentlich schon immer.

Systemd startet einen Prozess, ohne sich tiefergehend dafür zu interessieren, was der Job tut. Was m.E. so auch richtig angesetzt ist. Beendet sich der Job mit exit 0 betrachtet Systemd den Vorgang als erfolgreich abgeschlossen.

Nun passiert aber folgendes: Der Job forked sich .... der Parent generiert einen neuen Prozess, den Child-Prozess, der vermutlich als Daemon im Hintergrund laufen soll. Bildlich gesprochen zündet der Parent die Lunte einer Sylvesterrakete (sein Fork) an, dreht sich um und geht mit exit 0 nach hause. Er prüft nicht, ob die Rakete überhaupt startet und zu voller Pracht kommt ... vielleicht war die Lunte gebrochen, das Pulver feucht, der Stab zu fest in den Boden gerammt, usw usw.

Fakt ist, der Parent hätte kontrollieren müssen, ob der Start seines Forks erfolgreich war und hätte erst dann mit passendem Returncode zurückkehren dürfen. Mit 0 bei Erfolg, ungleich 0 bei Misserfolg. Erst dann kann Systemd die Abhängigkeiten ordentlich handhaben. Aber das gilt m.M.n. schon immer, auch schon unter sysvinit. Wenn so ein Prozess failed ist das weder Systemd noch überhaupt irgendeinem startsystem anzulasten. Und wenn ein Startsystem solche Fälle handhaben kann, würde ich dem Startsystem vorhalten, dass es schlampige Programmierung fördert, was natürlich deutlich schlechter für die Integrität des Computersystems als ganzes ist.

Richtig wäre imho, wenn der Fork bestätigt, das alles gut ist. Erst dann geht der Parent 'nach hause'. Dann kann es auch nicht zu solchen Situationen kommen.

[MSfree]

Was hat das mit der ursprünglichen Frage zu tun?

dass ich in Frage stelle, das -ich zitiere- "Ich muss es immer explizit überprüfen" überhaupt notwendig ist.

Du hast die falsche Einstellung.

Wenn ich, aus welchen Gründen auch immer, einen bisher funktioneirenden Apache umkonfiguriere und dabei einen kleinen Syntaxfehler in die Konfiguration bastele, dann bringt mir ein systemclt restart apache, daß alle OK ist. Erst, wenn ich dann mit einem Browser den Server testen will, stelle ich fest, daß der gar nicht mehr läuft. Zum Vergleich: beim alten SysV-Init hätte ich die Ausgabe auf stderr, den apache in diesem Fall geschrieben hätte, sofort und ohne Umweg gesehen.

Und andersrum, wenn ich mit dem Prinzip "Service-Unit" experimentiere, dann mach ich das nicht mit einem Produktiv-Job, sondern mit irgendwas harmlosen, unwichtigen, was nix kaputt machen kann.Und dabei ist der Job nur sekundär wichtig. Da gilt mein Augenmerk der Service-Unit.

Es ist völlig egal, ob man das mit einem Testsystem, mit einer Testunit oder einem Lifesystem macht, versehentliche Fehler werden erst aufgedeckt, nachdem man feststellt, daß der Server nicht reagiert und man daraufhin im Log nachgesehen hat.

Wie oft das passiert, ist hierbei komplett nebensächlich. Es ist sogar so, je seltnener man so etwas macht, desto weniger denkt man dabei an möglicherweise auftretende Fehler, weil man die einfach nicht auf dem Radar hat.

Insofern ist deine Frage: "Wie oft passiert es, dass der Dienst nicht korrekt gestartet wurde?" sogar so zu sehen, daß je seltener sowas passiert, desto ärgerlicher ist es, desto wichtiger wäre es, daß systemd die Fehlermeldungen nicht einfach verschluckt und den Anwender im Unklaren läßt.

[ralli]

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.

[TomL]

Insofern ist deine Frage: "Wie oft passiert es, dass der Dienst nicht korrekt gestartet wurde?" sogar so zu sehen, daß je seltener sowas passiert, desto ärgerlicher ist es, desto wichtiger wäre es, daß systemd die Fehlermeldungen nicht einfach verschluckt und den Anwender im Unklaren läßt.

Da bin ich halt völlig anderer Meinung. Warum sollte systemd überhaupt für meine fehlende Sorgfalt verantwortlich sein oder mich überhaupt auf irgendwas hinweisen? Das ist doch gar nicht seine Aufgabe. Es soll allein meinen Job starten, so wie ich das eingestellt habe und fertig. Das der Job so eingestellt ist, oder programmiert ist, dass er fehlerfrei laufen kann, ist MEINE Verantwortung, nicht die von systemd. All das regel ich doch vorher, bevor ich den Job überhaupt als Dienst via Service-Unit starten würde.

Auch die die geforderte fehlende Geschwätzigkeit des Prozessstatus laste ich nicht systemd an, sondern das ist imho auch Sache des Jobs selber. Wie du oben in meinem NetworkWaitOnline-Beispiel siehst, kann ich vom Start bis Ende des Jobs verfolgen, ob das erfolgreich war. Und wenn ich hier einen USB-Stick als Crypt-Key einstecke, kann ich meinen Prozess vom vordefinierten Mounten bis zum Unmount auch komplett verfolgen:

Code: Alles auswählen

journalctl -f
Feb 09 10:50:45 thomaspc systemd[1]: Starting Running /usr/local/bin/usbmount...
Feb 09 10:50:45 thomaspc thlu:usbmount[3154]: Started: start 'device=sdc1,mountto=/home/thomas/.keys'
Feb 09 10:50:45 thomaspc thlu:usbmount[3166]: Action=start   Device=/dev/sdc1   MountTo=/home/thomas/.keys   Run= Arg1= Arg2= Arg3=
Feb 09 10:50:45 thomaspc thlu:usbmount[3181]: Model: ATTRS{model}=="Cruzer Fit "  Serialid: ATTRS{serial}=="4C41411441" ATTRS{serial}=="0000:00:13.2"
Feb 09 10:50:45 thomaspc thlu:usbmount[3200]: /bin/mount /dev/sdc1 /home/thomas/.keys    (FSType=vfat)  (RC mount=0)
Feb 09 10:50:45 thomaspc systemd[1]: Started Running /usr/local/bin/usbmount.

Feb 09 10:51:53 thomaspc kernel: usb 2-3: USB disconnect, device number 2
Feb 09 10:51:53 thomaspc systemd[1]: Stopping Running /usr/local/bin/usbmount...
Feb 09 10:51:53 thomaspc thlu:usbmount[3219]: Started: stop 'device=sdc1,mountto=/home/thomas/.keys'
Feb 09 10:51:53 thomaspc thlu:usbmount[3236]: Action=stop   Device=/dev/sdc1   MountTo=/home/thomas/.keys   Run= Arg1= Arg2= Arg3=
Feb 09 10:51:53 thomaspc thlu:usbmount[3240]: /bin/umount /dev/sdc1 -f    (RC umount=0)
Feb 09 10:51:53 thomaspc systemd[1]: Stopped Running /usr/local/bin/usbmount.

Ich sehe, mit welchem Parameter derJob gestartet wurde, wie der Parameter geparsed wurde, was weiterhin an Folgeprozessen dranhängt und wie die ausgegangen sind, sowohl beim reinstecken als auch beim Abziehen. Wenn so etwas heute bei verschiedenen Prozessen zum Teil nicht funktioniert , ist das m.E. der Beibehaltung des Prozesses von sysvinit-Gewohnheiten geschuldet. Und diesen Vorwurf mache ich z.B. systemd, systemd hätte besser besser von Anfang an keine init.d-Scripte unterstützen dürfen. Genau daraus resultieren imho viele Probleme, die es ohne init.d unter systemd gar nicht mehr gegeben hätte. Aber wahrscheinlich ist es eher so, dass es gar nicht anders möglich war, weil bis zum Releasezeitpunkt 'Jessie" eben niemals alles hätte umgestellt werden können.

Ich glaube, dass hier schlichtweg eine falsche Erwartungshaltung an systemd gekoppelt wird. systemd ist imho ein "starter" von Prozessen, nicht mehr und nicht weniger..... und es hat sich gefälligst nicht darum zu kümmern, was meine Prozesse wie oder wann und ob überhaupt tun, da kümmere ich mich schon selber drum.... allenfalls eben nur so, dass es den Prozess ordentlich startet, dass es die Meldungen des Prozesses ordentlich handhabt.... und das tut es, wie man in meinen Beispielen sieht, oder eben das es gestorbene Jobs (ohne Rückmeldung) nach dem obligatorischen Timeout wieder entfernt. Alles andere ist imho Sache des Jobs.

[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