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
service/systemd gesprächiger machen
-
- Beiträge: 3020
- Registriert: 03.11.2009 13:45:23
- Lizenz eigener Beiträge: Artistic Lizenz
-
Kontaktdaten:
Re: service/systemd gesprächiger machen
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
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
Re: service/systemd gesprächiger machen
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.
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.
Re: service/systemd gesprächiger machen
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.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).
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"
Code: Alles auswählen
/bin/bash -c "/usr/bin/env >/root/lsenv2"
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.
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 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.
Re: service/systemd gesprächiger machen
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.
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.