service/systemd gesprächiger machen

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: service/systemd gesprächiger machen

Beitrag von scientific » 09.02.2017 20:03:54

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
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

MoonKid
Beiträge: 513
Registriert: 12.03.2012 22:36:43

Re: service/systemd gesprächiger machen

Beitrag von MoonKid » 10.02.2017 13:34:31

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

Re: service/systemd gesprächiger machen

Beitrag von TomL » 10.02.2017 18:18:47

MoonKid hat geschrieben: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.
MoonKid hat geschrieben: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
Beiträge: 513
Registriert: 12.03.2012 22:36:43

Re: service/systemd gesprächiger machen

Beitrag von MoonKid » 11.02.2017 13:49:14

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.

Antworten