staging.inyokaproject.org

noisefloor schrieb:

da sollten wir nochmal drüber gehen.

Weil?

Weil der Artikel teilweise noch fehlerhaft ist - wie im angesprochenen Beispiel:

Requires= 

beendet den Dienst nicht wenn die Abhängigkeit beendet wird.

Die korrigierten Abhängigkeiten würde ich aber nach systemd/Units verschieben,

Units bestehen ja nicht nur aus Services. Ich habe bspw. Services, die abhängig von NFS-Mounts sind. Sowas lässt sich mit systemd.mounts prima abbilden - zumal im Hintergrund ja sowieso systemd werkelt. Und einige Mount-Probleme, die Leute im Forum haben, lassen sich damit auch lösen.

Den Artikel gibt's aber gar nicht...?

Genau. Der Großteil aus diesem Artikel hier bezieht sich aber auf Units im Allgemeinen und nicht nur auf Services. Wenn ich jetzt bspw. einen Artikel für systemd.mounts schreibe (und den schön kurz halten will), dann fehlen dort entweder entscheidende Dinge oder wir haben einen großen Teil Redundanz.

Daher habe ich mal einen Entwurf für Baustelle/systemd/Units gewagt. Der Inhalt dürfte dir nicht neu sein - denn er beinhaltet alles Unit-relevante aus diesem Artikel hier. (womit dann dieser Artikel hier kürzer werden und sich auf die Service_Units konzentrieren kann).

Bevor du dich in den weiten Untiefen von systemd verlierst: Das Wiki ersetzt _nicht_ die Dokumentation (von systemd), d.h. es muss _nicht_ jeder Fall abdeckt werden.

Stimmt. Ich halte die Manpages von systemd für sehr gelungen. U.a. sind sie genau so angelegt: Units, Service_Units, Mount_Units, etc. Für mich als Einsteiger war das super, um mich zurecht zu finden. Diese Struktur würde ich hier gerne beibehalten. Spricht denn etwas dagegen?

Hallo,

allgemeine Teile auslagern ist ok. (Noch) werden ja nicht alle Unit-Arten im Wiki hier behandelt bzw. am Anfang waren es ja nur die Service- und Timer-Units, da machte das Auslagern noch nicht so viel Sinn.

Gruß, noisefloor

noisefloor schrieb:

Hallo,

allgemeine Teile auslagern ist ok.

Schön. Ich hatte schon die Befürchtung dass das systemd-Thema nicht nur die Linux-Welt, sondern auch das Wiki-Team spaltet 😀 . Dann kann ich ja weiter machen... 👍

(Noch) werden ja nicht alle Unit-Arten im Wiki hier behandelt bzw. am Anfang waren es ja nur die Service- und Timer-Units, da machte das Auslagern noch nicht so viel Sinn.

Sehe ich genauso. Die Artikel sind ja aber eine super Grundlage. Mit wachsendem Inhalt hat man halt immer wieder die Herausforderung der Struktur.

So, alle allgemeingültigen Units-Abschnitte habe ich ausgelagert in die Baustelle/systemd/Units . Damit der Artikel trotzdem lesbar bleibt, habe ich ein paar Abschnitte und Sätze umgestellt. Mag mal jemand gegen lesen?

Ich würde noch einen kleinen Abschnitt zu den user-units einfügen. Der Aufbau ist ja gleich, nur das Rechtesystem dahinter ein anderes.

Benutzerspezifische Dinge gehören ja eigentlich™ nicht nach /etc.

Das kannte ich noch gar nicht. Gehört dann aber nach Baustelle/systemd/Units, weil nicht service-spezifisch.

//edited: und wie startet man die Units dann? Hast du da ein Beispiel?

BillMaier schrieb:

Das kannte ich noch gar nicht. Gehört dann aber nach Baustelle/systemd/Units, weil nicht service-spezifisch.

👍

Artikel ist wieder im Wiki.

Hallo zusammen,

In systemd/Service Units (Abschnitt „Selbst-angelegte-Service-Units-aktivieren“) steht am Ende der Befehl:

sudo systemctl edit SERVICEUNIT  

, aber eigentlich ohne thematischen Bezug zum Abschnitts-Thema.

Sollte stattdessen nicht lieber – analog zu systemd/Units (Abschnitt „Bestehende-Unit-editieren“):

• eine eigene Abschnitts-Überschrift angelegt werden,

• sowie der Befehl mit --full zu

  sudo systemctl edit --full SERVICEUNIT  

  ergänzt werden?

Hallo,

habe den Abschnitt komplett entfernt, weil 100% redundant mit dem Abschnitt in systemd/Units.

Gruß, noisefloor