service/systemd gesprächiger machen

[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.