staging.inyokaproject.org

Hallo,

im Zuge der Erweiterung des Wikiartikels zum Umgebungsvariablen hier der Artikel zu systemd Umgebungsvariablen.

Ergänzungen, Korrekturen sind willkommen ☺

Gruß, noisefloor

jetzt bist mir zuvor gekommen. Hatte das auch schon auf der Agenda 😉

Hallo,

kannst ja zum Ausgleich einen Artikel zu socket-Units schreiben. Den habe ich für irgendwann (...) auf der Agenda 😉

Gruß, noisefloor

Ne, da kenn ich mich noch nicht aus. Hab noch andere Baustellen hier, die ich mal abschließen sollte, bevor ich neue aufmache 😉

Ich würde noch die Option PassEnvironment= erwähnen, sonst hat man wenig von den für Systemd global gesetzten Umgebungsvariablen.

Hallo, mir gefällt der Artikel vom Aufbau. Schön verständlich.

Hier noch ein paar Anmerkungen:

#alternativ:
systemctl show | grep Environment  

finde ich kein gutes Beispiel, da auch eine Variable namens Environments angezeigt würde. Besser fände ich etwas in der Art wie:

Um alle Variablen anzuzeigen ...

systemctl show 

Einzelne Variablen lassen sich mit

systemctl show --property Environment 

abfragen.

Grund: Es ist einfach präziser. Wer grep kennt, weiß es sowieso einzusetzen und sollte dann auch um seine Begrenztheit (und Möglichkeiten wie -w) wissen.

1. das Editieren der Datei /etc/systemd/system.conf .

Da bin ich ja immer dagegen, genau wie bei /etc/profile und Konsorten. Man sollte wo immer möglich die .d -Verzeichnisse verwenden.

Der Zugriff auf Umgebungsvariablen von systemd erfolgt mit einem Bash-ähnlichen Syntax.

Im darauf folgenden Beispiel ja nur deshalb, weil man ein Shell-Skript ausführt, oder? Wird dann erst mit dem nächsten Abschnitt klarer, dass das auch innerhalb der Unit so ist. Vielleicht kriegst du das noch klarer?

Viele Grüße

BillMaier

Hallo,

bei /etc/systemd/system.conf sind bei Ubuntu ootb alle Zeilen auskommentiert. Von daher spricht da IMHO nichts gegen, dass zu editieren.

@seahawk1986:

Ich würde noch die Option PassEnvironment= erwähnen, sonst hat man wenig von den für Systemd global gesetzten Umgebungsvariablen.

Wie meinst du das? Wenn ich eine Variable per Kernel Parameter oder in der system.conf deklariere, dann sind die doch in für alle Units bekannt...? Jedenfalls habe ich beim Testen nichts gegenteiliges festgestellt.

Gruß, noisefloor

Hallo,

habe die Anmerkungen von BillMaier eingearbeitet.

Gruß, noisefloor

noisefloor schrieb:

Hallo,

habe die Anmerkungen von BillMaier eingearbeitet

... und dabei korrigiert, was ich nicht verstanden hatte. Danke.

Der Abschnitt systemd.conf bzw. systemd.conf.d funktioniert nur leider so noch nicht, weil der Fließtext die Reihenfolgenänderung nicht mit macht. Also das müsste entweder noch umgestrickt werden - oder eben wieder zurück.

noisefloor schrieb:

bei /etc/systemd/system.conf sind bei Ubuntu ootb alle Zeilen auskommentiert. Von daher spricht da IMHO nichts gegen, dass zu editieren.

kann ich hier sogar als Argument gelten lassen. Auch wenn ich es immer noch nicht gut finde 😉

Hallo,

Der Abschnitt systemd.conf bzw. systemd.conf.d funktioniert nur leider so noch nicht, weil der Fließtext die Reihenfolgenänderung nicht mit macht. Also das müsste entweder noch umgestrickt werden - oder eben wieder zurück.

Was meinst du damit? Sieht doch alles aus, wie es soll - siehe Anhang.

Wenn seahawk1986 sich noch meldet bzgl. PassEnvironmentwäre der Artikel IMHO fertig.

Gruß, noisefloor

noisefloor schrieb:

Hallo,

Der Abschnitt systemd.conf bzw. systemd.conf.d funktioniert nur leider so noch nicht, weil der Fließtext die Reihenfolgenänderung nicht mit macht. Also das müsste entweder noch umgestrickt werden - oder eben wieder zurück.

Was meinst du damit? Sieht doch alles aus, wie es soll - siehe Anhang.

Ich meine, es funktioniert inhaltlich / von der Formulierung noch nicht:

Du startest mit "Alternativ kann" und im zweiten Abschnitt geht es weiter mit "In der Datei /etc/systemd/system.conf gibt es in der Sektion [Manager] eine Zeile" ...

Gruß BillMaier

PassEnvironment dient dazu die Umgebungsvariablen, die Systemd als Init-System (typischerweise in einem Container) bekommt, an die von ihm gestarteten Prozesse durchzureichen.

Wenn man z.B. einen Container mit systemd-nspawn mit dem Argument --setenv=FOO=BAR bootet (https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#-E%20NAME=VALUE), kann man auf die Umgebungsvariable FOO mit einer Unit im Container nur zugreifen, wenn man mit PassEnvironment=FOO für eine Unit festlegt, dass die Variable durchgereicht werden soll.

Hallo,

aha - habe ich so selber noch nicht genutzt. Hab's mal nach besten Wissen und Gewissen eingebaut. Bitte mal drüber schauen, ob das so passt.

Gruß, noisefloor

Hallo,

keine weiteren Rückmeldungen, Artikel ist im Wiki.

Gruß, noisefloor

Hallo,

hab beim Überarbeiten der anderen Umgebungsvariablen-Artikel noch was entdeckt, was hier event. interessant sein könnte. Zumindest hab ich es auf Anhieb im Artikel nicht gefunden. Kenne mich aber zu wenig damit aus, deshalb poste ich es mal hier:

B. Das Programm systemd im Benutzer-Modus (Option --user) ermöglicht es, Umgebungsvariable beim Start zu setzen:

1. Anstelle der oben für den systemd-Daemon im Systemmodus genannten Dateien verwendet man /etc/systemd/user.conf oder /etc/systemd/user.d/*.conf.

2. systemd ab Version 233 implementiert zusätzlich eine Spezifikation von freedesktop über "environment-generators". Diese sind bei Ubuntu-Systemen erst ab Version 17.10 mit systemd-Version 234 benutzbar und werden über Textdateien konfiguriert. In diesen Textdateien kann man für die Variablendefinition einige Shell-Konstrukte benutzen, wie Aufruf alter Werte ($NAME und ${NAME}), Default-Werte (${NAME:-Vorgabe}) und Ersatzwerte (${NAME:+Ersatz}).

   1. Beim Start eines systemd-Daemons für einen Benutzer werden Dateien *.conf in den im folgenden aufgeführten Verzeichnissen abgearbeitet. Dabei maskieren Dateien unter /etc/ gleichnamige Dateien unter /run/ und Dateien unter /run/ maskieren gleichnamige unter /usr/:

      • /etc/environment.d/

      • /run/environment.d/

      • /usr/lib/environment.d/

      • Die Datei /etc/environment kann/soll man per Symlink in /etc/environment.d/ einbinden.

   2. Anschließend werden auch noch Dateien ~/.config/environment.d/*.conf im HOME-Verzeichnis des Benutzers ausgewertet.

Änderungen in diesen Dateien werden erst beim nächsten Start eines systemd-Daemons im Benutzer-Modus wirksam.

Quelle: kB 😉

Viele Grüße

BillMaier