So lesen Sie Umgebungsvariablen eines Prozesses

Linux /proc/<pid>/environwird nicht aktualisiert (soweit ich weiß, enthält die Datei die ursprüngliche Umgebung des Prozesses).

Wie kann ich die aktuelle Umgebung eines Prozesses lesen ?

/proc/$pid/environwird aktualisiert, wenn der Prozess seine eigene Umgebung ändert. Viele Programme machen sich jedoch nicht die Mühe, ihre eigene Umgebung zu ändern, da dies etwas sinnlos ist: Die Umgebung eines Programms ist nicht über normale Kanäle sichtbar, sondern nur über /procund ps, und nicht jede Unix-Variante verfügt über diese Funktion, sodass Anwendungen nicht darauf angewiesen sind darauf.

Für den Kernel erscheint die Umgebung nur als Argument des execveSystemaufrufs, der das Programm startet. Linux macht einen Bereich im Arbeitsspeicher durch verfügbar /proc, und einige Programme aktualisieren diesen Bereich, während andere dies nicht tun. Insbesondere glaube ich nicht, dass eine Shell diesen Bereich aktualisiert. Da der Bereich eine feste Größe hat, ist es unmöglich, neue Variablen hinzuzufügen oder die Länge eines Werts zu ändern.

Sie können die ursprüngliche Umgebung eines Prozesses aus lesen /proc/<pid>/environ.

Wenn ein Prozess seine Umgebung ändert , müssen Sie zum Lesen der Umgebung über die Symboltabelle für den Prozess verfügen und den ptraceSystemaufruf (z. B. mithilfe von gdb) verwenden, um die Umgebung aus der globalen char **__environVariablen zu lesen . Es gibt keine andere Möglichkeit, den Wert einer Variablen aus einem laufenden Linux-Prozess abzurufen.

Das ist die Antwort. Nun zu einigen Notizen.

Bei den obigen Ausführungen wird davon ausgegangen, dass der Prozess POSIX-kompatibel ist. Dies bedeutet, dass der Prozess seine Umgebung mithilfe einer globalen Variablen verwaltet char **__environ, die in der Referenzspezifikation angegeben ist .

Die ursprüngliche Umgebung für einen Prozess wird in einem Puffer fester Länge auf dem Prozessstapel an den Prozess übergeben. (Der übliche Mechanismus hierfür ist der folgende linux//fs/exec.c:do_execve_common(...).) Da die Größe des Puffers so berechnet wird, dass sie nicht größer ist als die für die ursprüngliche Umgebung erforderliche Größe, können Sie keine neuen Variablen hinzufügen, ohne vorhandene Variablen zu löschen oder den Stapel zu zerschlagen. Jedes vernünftige Schema, um Änderungen in der Umgebung eines Prozesses zuzulassen, würde den Heap verwenden, in dem Speicher in beliebigen Größen zugewiesen und freigegeben werden kann. Genau das macht GNU libc( glibc) für Sie.

Wenn der Prozess verwendet glibc, ist er POSIX-kompatibel. Wenn __environer in glibc//posix/environ.cGlibc deklariert wird, wird er __environmit einem Zeiger auf den Speicher initialisiert , der mallocaus dem Heap des Prozesses stammt. Anschließend wird die ursprüngliche Umgebung vom Stapel in diesen Heapbereich kopiert. Jedes Mal, wenn der Prozess die setenvFunktion verwendet, glibcwird a ausgeführt realloc, um die Größe des Bereichs anzupassen, auf den __environder neue Wert oder die neue Variable verweist. (Sie können den glibc-Quellcode mit herunterladen git clone git://sourceware.org/git/glibc.git glibc). Um den Mechanismus wirklich zu verstehen, müssen Sie auch den Hurd-Code einlesen hurd//init/init.c:frob_kernel_process()(git clone git: //git.sv.gnu.org/hurd/hurd.git hurd).

Wenn der neue Prozess nur forkbearbeitet wird, ohne execden Stapel anschließend zu überschreiben, wird das Argument und die Umgebung kopiert. Dabei ruft linux//kernel/fork.c:do_fork(...)die copy_processRoutine auf dup_task_struct, die den Stapel des neuen Prozesses durch Aufrufen von alloc_thread_info_nodeaufruft setup_thread_stack( linux//include/linux/sched.h) für den neuen Prozess mit alloc_thread_info_node.

Schließlich ist die POSIX- __environKonvention eine User-Space- Konvention. Es hat keine Verbindung mit irgendetwas im Linux-Kernel. Sie können ein Userspace-Programm ohne glibcund ohne das __environGlobale schreiben und dann die Umgebungsvariablen verwalten, wie Sie möchten. Niemand wird Sie dafür verhaften, aber Sie müssen Ihre eigenen Umgebungsverwaltungsfunktionen ( setenv/ getenv) und Ihre eigenen Wrapper dafür schreiben, sys_execund es ist wahrscheinlich, dass niemand ahnen kann, wo Sie die Änderungen an Ihrer Umgebung vorgenommen haben.

Es wird aktualisiert, wenn der Prozess seine Umgebungsvariablen erfasst / löscht. Haben Sie eine Referenz, die besagt, dass die environDatei für den Prozess in ihrem Prozessverzeichnis unter / proc Dateisystem nicht aktualisiert wurde?

xargs --null --max-args=1 echo < /proc/self/environ

oder

xargs --null --max-args=1 echo < /proc/<pid>/environ

oder

ps e -p <pid>

Mit dem obigen Befehl werden die Umgebungsvariablen des Prozesses im psAusgabeformat gedruckt. Eine Textverarbeitung (Parsen / Filtern) ist erforderlich, um die Umgebungsvariablen als Liste anzuzeigen.

Solaris (nicht gefragt, aber als Referenz werde ich hier posten):

/usr/ucb/ps -wwwe <pid>

oder

pargs -e <pid> 

EDIT: / proc / pid / environ wird nicht aktualisiert! Ich stehe korrigiert. Überprüfungsprozess ist unten. Die untergeordneten Elemente, von denen der Prozess abgeleitet wurde, erben jedoch die Prozessumgebungsvariable und diese wird in der jeweiligen Datei / proc / self / environ angezeigt. (Benutze Strings)

Mit in der Shell: Hier ist xargs ein untergeordneter Prozess und erbt daher die Umgebungsvariable und spiegelt sich auch in seiner /proc/self/environDatei wider .

[centos@centos t]$ printenv  | grep MASK
[centos@centos t]$ export MASK=NIKHIL
[centos@centos t]$ printenv  | grep MASK
MASK=NIKHIL
[centos@centos t]$ xargs --null --max-args=1 echo < /proc/self/environ  | grep MASK
MASK=NIKHIL
[centos@centos t]$ unset MASK
[centos@centos t]$ printenv  | grep MASK
[centos@centos t]$ xargs --null --max-args=1 echo < /proc/self/environ  | grep MASK
[centos@centos t]$

Überprüfung aus einer anderen Sitzung, in der das Terminal / die Sitzung nicht der untergeordnete Prozess der Shell ist, in der die Umgebungsvariable festgelegt ist.

Überprüfung von einem anderen Terminal / einer anderen Sitzung auf demselben Host:

terminal1 :: Beachten Sie, dass printenv fork'd und ein untergeordneter Prozess von bash ist und daher seine eigene Umgebungsdatei liest.

[centos@centos t]$ echo $$
2610
[centos@centos t]$ export SPIDEY=NIKHIL
[centos@centos t]$ printenv | grep SPIDEY
SPIDEY=NIKHIL
[centos@centos t]$ 

terminal2: auf demselben Host - starten Sie es nicht in derselben Shell, in der die obige Variable festgelegt wurde, sondern starten Sie das Terminal separat.

[centos@centos ~]$ echo $$
4436
[centos@centos ~]$ xargs --null --max-args=1 echo < /proc/self/environ | grep -i spidey
[centos@centos ~]$ strings -f /proc/2610/environ | grep -i spidey
[centos@centos ~]$ xargs --null --max-args=1 echo < /proc/2610/environ | grep -i spidey
[centos@centos ~]$ 

Nun, das Folgende hängt nicht mit den wahren Absichten des Autors zusammen, aber wenn Sie das wirklich "LESEN" wollen /proc/<pid>/environ, können Sie es versuchen

strings /proc/<pid>/environ

was ist besser als cates.