staging.inyokaproject.org

Hallo,

zwecks Ergänzung in der Baustelle.

Gruß, noisefloor

Hallo,

Nein. Es gibt dann 2 Units mit demselben Namen (z.B. apache.service): eine systemweite Unit apache.service und eine benutzerbezogene Unit apache.service. Beide existieren völlig unabhängig voneinander. Benutzerbezogene Units können systemweite Units nicht überschreiben.

So ähnlich: der Name einer Unit muss zu Laufzeit der aktiven Unit einmalig sein. Heißt, um beim Beispiel zu bleiben, kannst du die User-Unit apache.service so wie so nicht starten, wenn die systemweite Unit apache.service läuft. Und systemweite Units werden ja quasi zwangsläufig vor User Units gestartet.

Gruß, noisefloor

Warum?

Wenn eine unit auf disabled steht und man dann die user-basierte startet?

Wird schon sehr speziell jetzt und wir müssen auch nicht alles berücksichtigen. Richtig sollte es dennoch sein...

Hallo,

Wenn eine unit auf disabled steht und man dann die user-basierte startet?

Aktiv meinte ich als "von systemd gestartet". War missverständlich ausgedrückt. Da ja auch auf "disabled" stehende Units von systemd gestartet werden können.

Gruß, noisefloor

Hallo, im Artikel kommen wir meiner Vorstellung näher. Ich habe mir erlaubt, in der Baustelle

• noch Zwischenüberschriften einzufügen und die Überschrift-Ebenen anzupassen.

• ein Pendant zu den systemweiten Units in den benutzerbezogenen Units unter zu bringen bzgl. des "Überschreibens"

• Kleinigkeiten zu ändern.

Bitte schaut doch mal drauf.

Frage:

* /usr/lib/systemd/user: Hier liegen alle vorinstallierten Dateien von Units für benutzerbezogene Dienste. Änderungen sind nur mit Root-Rechten möglich.

Machen hier Änderungen überhaupt Sinn? (Grundsätzlich denke ich ja, weil man so als Admin die benutzerbezogenen Dienste für alle Nutzer anpassen kann). Aber: wie sieht es da mit Updates aus?

Noch zur Vollständigkeit (vermutlich aber nur ein Lesefehler/Missverständnis):

rolands11 schrieb:

BillMaier schrieb:

▶ Wenn ich hier eine gleichnamige Unit wie in /usr/lib/systemd/user anlege, wird diese dann dadurch ebenfalls "überschrieben" bzw. "editiert" ?

Danke für den Hinweis, das war in der Tat nicht ganz klar.

Nein. Es gibt dann 2 Units mit demselben Namen (z.B. apache.service): eine systemweite Unit apache.service und eine benutzerbezogene Unit apache.service. Beide existieren völlig unabhängig voneinander. Benutzerbezogene Units können systemweite Units nicht überschreiben.

Also wäre die Antwort ja und nicht nein, denn ich hatte ja geschrieben:

    ~/.config/systemd/user: Hier liegen alle Dateien von benutzerbezogenen Units, welche durch den Nutzer angelegt oder editiert werden. Dazu sind keine Root-Rechte[1] erforderlich.

▶ Wenn ich hier eine gleichnamige Unit wie in /usr/lib/systemd/user anlege, wird diese dann dadurch ebenfalls "überschrieben" bzw. "editiert" ?

Viele Grüße

BillMaier

Hallo,

so, fertig. Div. kleine Änderungen gemacht, in erster Linie bezogen auf den systemd/User Unit Artikel. Beide Artikel können / müssten dann zusammen aus der Baustelle.

Gruß, noisefloor

Passt. Keine Fehler gefunden.

Gruß BillMaier

Hallo,

Artikel ist wieder im Wiki.

Gruß, noisefloor

Quoting scheint hier nicht gewünscht zu sein.

Gültig:

BindsTo=mnt-nfs.mount
AssertPathIsMountPoint=/mnt/nfs
AssertPathIsReadWrite=/mnt/nfs

ungültig:

BindsTo="mnt-nfs.mount"
AssertPathIsMountPoint="/mnt/nfs"
AssertPathIsReadWrite="/mnt/nfs"

Sollten wir das noch erwähnen oder bin ich der einzige der "automatisch" quotet?

Hallo,

keine Ahnung. Ich habe jedenfalls noch nie den Drang verspürt, zu quoten.

Zumal auch Zeilen wie ExecStart=/usr/local/bin/gunicorn -b 127.0.0.1:8001 --env DJANGO_SETTING_MODULE=gc_django.settings gc_django.wsgi ohne Probleme funktionieren. systemd Units sind halt keine Shellskripte.

Nachtrag: siehe auch https://www.freedesktop.org/software/systemd/man/systemd.service.html#Command%20lines

Gruß, noisefloor

Hallo zusammen,

in systemd/Units (Abschnitt „Bestehende-Unit-editieren“) steht:

Mit dem Befehl

sudo systemctl edit --full NAME_DER_UNIT_DATEI 

wird eine Kopie der Unit-Datei aus /lib/systemd/system im Verzeichnis /etc/systemd/system angelegt, und der Standardeditor des Systems öffnet diese Datei zum Editieren. Nach dem Speichern und Schließen des Editors wird die Unit automatisch neu geladen.

Dabei wird aber automatisch vorausgesetzt bzw. es ist in diesem Fall so, dass man eine bereits bestehende, von systemd "ab Werk mitgebrachte" Unit als Grundlage für seine eigene, angepasste Unit verwenden möchte.

Falls man demgegenüber aber dann seine eigene, angepasste Unit editieren möchte, ist wohl ein etwas modifizierter Befehl notwendig, bzw. wie sollte/muss man in diesem Fall vorgehen, und ist dieses Prozedere auch reif dafür, im Artikel erwähnt zu werden?

systemd/systemctl (Abschnitt „Bearbeiten-von-Unit-Dateien“)

sollte dann aber IMHO zusammen in einen Artikel, am ehesten wohl nach systemctl . Und das systemctl edit --full sollte dann hier aus dem Artikel raus und nur noch verlinkt werden.

Gruß BillMaier

//edit: korrigiert

linux_joy schrieb:

…Dabei wird aber automatisch vorausgesetzt bzw. es ist in diesem Fall so, dass man eine bereits bestehende, von systemd "ab Werk mitgebrachte" Unit als Grundlage für seine eigene, angepasste Unit verwenden möchte.

Der Befehl funktioniert auch bei eigenen Units, die man unter /etc/systemd/system/ hinterlegt hat - oder mit der weiteren Option --force dort neu anlegt.

Oder habe ich den Inhalt deiner Frage nicht verstanden?

Hallo zusammen!

ChickenLipsRfun2eat schrieb:

linux_joy schrieb:

…Dabei wird aber automatisch vorausgesetzt bzw. es ist in diesem Fall so, dass man eine bereits bestehende, von systemd "ab Werk mitgebrachte" Unit als Grundlage für seine eigene, angepasste Unit verwenden möchte.

Der Befehl funktioniert auch bei eigenen Units, die man unter /etc/systemd/system/ hinterlegt hat - oder mit der weiteren Option --force dort neu anlegt.

Oder habe ich den Inhalt deiner Frage nicht verstanden?

Konkret geht es mir einfach darum, ob es möglicherweise einen Unterschied macht, ob ich das Editieren mit dem Befehl

sudo systemctl edit --full NAME_DER_UNIT_DATEI 

nun in /lib/systemd/system oder in /etc/systemd/system vornehme, denn in systemd/Units (Abschnitt „Bestehende-Unit-editieren“) steht ja:

(es) wird eine Kopie der Unit-Datei aus /lib/systemd/system im Verzeichnis /etc/systemd/system angelegt, und der Standardeditor des Systems öffnet diese Datei zum Editieren. Nach dem Speichern und Schließen des Editors wird die Unit automatisch neu geladen.

Falls ich nun den obigen Befehl auf eine bestehende Datei in /etc/systemd/system anwende, wird dann ebenfalls eine Kopie der besagten Unit-Datei irgendwo angelegt und nach dem Speichern und Schließen des Editors auch automatisch neu geladen? Oder etwa nicht? Denn in systemd/systemctl (Abschnitt „Bearbeiten-von-Unit-Dateien“) steht demgegenüber ja:

(...)
Um die ganze Unit-Datei zu bearbeiten dient die Option --full.

systemctl edit --full UNITNAME 

Nach abgeschlossenen Änderungen müssen diese mit mit

systemctl daemon-reload 

übernommen werden.

BillMaier schrieb:

systemd/systemctl (Abschnitt „Bearbeiten-von-Unit-Dateien“)

sollte dann aber IMHO zusammen in einen Artikel, am ehesten wohl nach systemctl . Und das systemctl edit --full sollte dann hier aus dem Artikel raus und nur noch verlinkt werden.

Gruß BillMaier

//edit: korrigiert

+1, aber es sollte, wie oben dargelegt, eben vorher geklärt werden, wann, wie und wo genau das mit dem Auto-Öffnen durch den System-Standardeditor und dem Auto-Reload der Unit funktioniert, dito der Gebrauch der weiteren Option --force!

linux_joy schrieb:

Konkret geht es mir einfach darum, ob es möglicherweise einen Unterschied macht, ob ich das Editieren mit dem Befehl … nun in /lib/systemd/system oder in /etc/systemd/system vornehme…

Wenn keine Kopie in /etc/… existiert, wird die zu bearbeitende aus /lib/… kopiert und bleibt nach dem Editieren auch da. Existiert schon eine Kopie, wird diese bearbeitet. Du kannst mit systemctl edit keine Datei mit absoluten Pfadangaben editieren, da diese /s durch Bindestriche ersetzt, um das Erstellen von bspw. mount-Units zu vereinfachen.

Du kannst also den Befehl nicht auf eine bestimmte Datei anwenden, das regelt systemd intern.

Die temporären Dateien liegen immer in /etc/systemd/system/ und heißen da .#NAME.service[NUMMER], gleich ob es eine "neue" Datei aus /lib/… ist oder eine bereits kopiert in /etc/…