GNU/Linux >> LINUX-Kenntnisse >  >> Linux

Portabilität von Dateideskriptor-Links?

Ich habe mich das schon immer gefragt, aber nie die Zeit genommen, es herauszufinden, also werde ich es jetzt tun – wie portabel ist die hier gezeigte Verwendung von entweder /proc/$$/fd/$N oder /dev/fd/$N ? Ich verstehe, dass POSIX /dev/null, /dev/tty, and /dev/console garantiert (obwohl ich das erst neulich herausgefunden habe, nachdem ich die Kommentare zu dieser Antwort gelesen hatte) aber was ist mit diesen anderen?

Soweit ich das beurteilen kann, sind sie ziemlich verbreitet, aber in welchen Systemen kann ich nicht erwarten, sie zu finden? Warum nicht? Ist es wahrscheinlicher, das eine zu finden als das andere? Werden sie immer ähnliche Eigenschaften aufweisen?

Ich neige dazu, diese Geräte ziemlich ausgiebig auf alle möglichen Arten zu verwenden, und ich würde gerne wissen, ob es eine Chance gibt, dass ich beim bloßen Versuch scheitern würde.

Auch sollten die obigen Fragen nur als das verstanden werden, was ich denke Ich würde es gerne wissen, aber da ich natürlich zuerst fragen muss, weiß ich in dieser Hinsicht vielleicht nicht am besten, und sie sollten nicht als strenge Anforderungen für eine Antwort angesehen werden. Informieren Sie mich einfach, wenn Sie können, bitte.

Akzeptierte Antwort:

Die /proc/PID/fd/NUM Symlinks sind unter Linux quasi universell, aber sie existieren nirgendwo anders (außer auf Cygwin, das sie emuliert). /proc/PID/fd/NUM gibt es auch unter AIX und Solaris, aber sie sind keine Symlinks. Um Informationen über geöffnete Dateien zu erhalten, installieren Sie lsof portabel .

Unices mit /proc/PID/fd

Linux

Unter Linux /proc/PID/fd/NUM ist ein leicht magischer symbolischer Link zu der Datei, die der Prozess mit der ID PID hat auf dem Dateideskriptor NUM geöffnet . Dieser Link ist insofern magisch, als er zum Beispiel verwendet werden kann, um auf die Datei zuzugreifen, selbst wenn die Datei entfernt wurde. Der Link verfolgt die Datei auch durch Umbenennungen. /proc/self ist ein magischer symbolischer Link, der auf /proc/PID wobei PID ist der Prozess, der auf den Link zugreift.

Diese Funktion ist auf praktisch allen Linux-Systemen vorhanden. Es wird vom Treiber für das proc-Dateisystem bereitgestellt, das technisch optional ist, aber für so viele Dinge verwendet wird (einschließlich der Erstellung des ps work – es liest aus /proc/PID ), dass es selbst auf eingebetteten Systemen fast nie ausgelassen wird.

Cygwin

Cygwin emuliert Linux’s /proc/PID/fd/NUM (für Cygwin-Prozesse) und /proc/self .

Solaris (ab Version 2.6), AIX

Es gibt /proc/PID/fd Einträge für jeden Dateideskriptor, aber sie erscheinen als vom gleichen Typ wie die geöffnete Datei, sodass sie keine Informationen über den Pfad der Datei liefern. Sie melden jedoch denselben stat Informationen als fstat würde an den Prozess berichten, der die Datei geöffnet hat, sodass es möglich ist, festzustellen, auf welchem ​​​​Dateisystem sich die Datei befindet und welche Inode-Nummer sie hat. Verzeichnisse erscheinen als symbolische Links, es handelt sich jedoch um magische symbolische Links, denen nur gefolgt werden kann, und readlink gibt einen leeren String zurück.

Unter AIX sind die procfiles Der Befehl zeigt einige Informationen über die geöffneten Dateien eines Prozesses an. Unter Solaris sind die pfiles Der Befehl zeigt einige Informationen über die geöffneten Dateien eines Prozesses an. Dies beinhaltet nicht den Pfad zur Datei (unter Solaris seit Solaris 10, siehe unten).

Solaris (seit Version 10)

Zusätzlich zu /proc/PID/fd/NUM , haben moderne Solaris-Versionen /proc/PID/path/NUM die symbolische Links ähnlich den Symlinks von Linux in /proc/PID/fd/NUM . Die pfiles Der Befehl zeigt Informationen über die geöffneten Dateien eines Prozesses an, einschließlich Pfade.

Plan9

/proc/PID/fd ist eine Textdatei, die einen Datensatz (Zeile) pro vom Prozess geöffneten Dateideskriptor enthält. Der Dateiname wird dort nicht verfolgt.

Verwandt:Dateinamen aus Pfad im awk-Programm extrahieren?

QNX

/proc/PID/ ist ein Verzeichnis, enthält aber keine Informationen über Dateideskriptoren.

Unices mit /proc aber kein direkter Zugriff auf Dateideskriptoren

(Hinweis:Manchmal ist es möglich, Informationen über die offenen Dateien eines Prozesses zu erhalten, indem man sein Speicherabbild durchblättert, auf das unter /proc zugegriffen werden kann . Ich zähle das nicht als „direkten Zugriff“.)

Unices wobei /proc/PID ist eine Datei

Das proc-Dateisystem selbst begann in UNIX 8th Edition, aber mit einer anderen Struktur, und ging durch Plan 9 und zurück zu einigen Unices. Ich denke, dass alle Betriebssysteme mit einem /proc haben einen Eintrag für jede PID, aber auf vielen Systemen ist es eine normale Datei, kein Verzeichnis. Die folgenden Systeme haben eine /proc/PID die mit ioctl gelesen werden muss :

  • Solaris bis zu 2,5
  • OSF/1 jetzt bekannt als Tru64
  • IRIX (?)
  • SCO (?)

MINIX 3

MINIX 3 hat einen procfs-Server, der mehrere Linux-ähnliche Komponenten bereitstellt, einschließlich /proc/PID/ Verzeichnisse. Es gibt jedoch keine /proc/PID/fd .

FreeBSD

FreeBSD hat /proc/PID/ Verzeichnisse, aber sie liefern keine Informationen über offene Dateideskriptoren. (Es gibt jedoch /proc/PID/file was ähnlich zu /proc/PID/exe , wodurch der Zugriff auf die ausführbare Datei über einen symbolischen Link ermöglicht wird.)

Die procfs von FreeBSD sind veraltet.

Unices ohne /proc

  • HP-UX
  • OpenBSD
  • NetBSD
  • Mac OS X

Dateideskriptorinformationen über andere Kanäle

Fixierer

Der fuser Der Befehl listet die Prozesse auf, die eine bestimmte Datei geöffnet haben, oder eine Datei, die am angegebenen Einhängepunkt geöffnet ist. Dieser Befehl ist Standard (verfügbar auf allen XSI-kompatiblen Systemen, d. h. POSIX mit der X/Open System Interface Extension).

Sie können mit diesem Dienstprogramm nicht von einem Prozess zu Dateinamen wechseln.

Lsof

Lsof steht für „list open files“. Es ist ein Drittanbieter-Tool, das für die meisten Unix-Varianten verfügbar (aber normalerweise nicht Teil der Standardinstallation) ist. Das Einholen von Informationen über geöffnete Dateien ist sehr systemabhängig, wie die obige Analyse Sie vermuten lassen könnte. Der lsof-Betreuer hat die Arbeit geleistet, alles unter einer einzigen Oberfläche zu vereinen.

Sie können die FAQ lesen, um zu sehen, mit welchen Schwierigkeiten lsof zu kämpfen hat. Auf den meisten Unices erfordert das Abrufen von Informationen über die Namen geöffneter Dateien das Analysieren von Kernel-Datenstrukturen. Zitat aus FAQ 3.3 „Warum meldet lsof keine vollständigen Pfadnamen?“:

Lsof kann keine Pfadnamenkomponenten aus den Kernelnamen-Caches der folgenden Dialekte abrufen:

  • AIX

Nur der Linux-Kernel zeichnet vollständige Pfadnamen in den Strukturen auf, die er über offene Dateien verwaltet; Stattdessen wandeln die meisten Kernel Pfadnamen in Dubletten von Geräte- und Knotennummern um und verwenden sie für nachfolgende Dateireferenzen, sobald Dateien geöffnet wurden.

Wenn Sie Informationen aus lsof parsen müssen verwenden Sie unbedingt das -F Modus (ein Feld pro Zeile), vorzugsweise -F0 Modus (durch Null getrennte Felder). Um Informationen über einen bestimmten Dateideskriptor eines bestimmten Prozesses zu erhalten, verwenden Sie den -a Option mit -p PID und -d NUM , z.B. lsof -a -p 123 -d 0 -F0n .

/dev/fd/NUM für Dateideskriptoren des aktuellen Prozesses

Viele Unix-Varianten bieten einem Prozess eine Möglichkeit, über einen Dateinamen auf seine geöffneten Dateien zuzugreifen:Öffnen von /dev/fd/NUM entspricht dem Aufruf von dup(NUM) . Diese Namen sind nützlich, wenn ein Programm einen Dateinamen haben möchte, Sie aber eine bereits geöffnete Datei (z. B. eine Pipe oder einen Socket) übergeben möchten. Beispielsweise verwenden die Shells, die die Prozessersetzung implementieren, diese, sofern verfügbar (unter Verwendung einer temporären benannten Pipe, wobei /dev/fd ist nicht verfügbar).

Wobei /dev/fd existiert, gibt es auch normalerweise (immer?) Synonyme (manchmal symbolische Links, manchmal harte Links, manchmal magische Dateien mit äquivalenten Eigenschaften) /dev/stdin =/dev/fd/0 , /dev/stdout =/dev/fd/1 , /dev/stderr =/dev/fd/2 .

  • Unter Linux /dev/fd ist ein symbolischer Link zu /proc/self/fd .
  • Unter den meisten Unices (IRIX, OpenBSD, NetBSD, SCO, Solaris, …) sind die Einträge in /dev/fd sind Zeichengeräte. Sie erscheinen normalerweise unabhängig davon, ob der Dateideskriptor geöffnet ist oder nicht, und für Dateideskriptoren über einer bestimmten Zahl sind möglicherweise keine Einträge verfügbar.
  • Unter FreeBSD und OSX bietet das fdescfs-Dateisystem ein dynamisches /dev/fd Verzeichnis, das den offenen Deskriptoren des aufrufenden Prozesses folgt. Ein statischer /dev/fd ist verfügbar, wenn /dev/fd ist nicht gemountet.
  • Unter OSF/1 (Tru64), /dev/fd wird über fdfs bereitgestellt.
  • Es gibt kein /dev/fd auf AIX oder HP-UX.
Verwandte:Ist es möglich, ein Zeichen am Terminal-Cursor mit ANSI-Escape-Codes zu erhalten?
Linux
  1. Verwalten von doppelten Cron-Jobs beim Ausführen von Skripten

  2. Wie kann ich einen Dateizeiger ( FILE* fp ) in einen Dateideskriptor (int fd) umwandeln?

  3. Maximale PID unter Linux

  4. Was ist eine .pid-Datei und was enthält sie?

  5. cp-L vs. cp-H

Ln-Befehl unter Linux (Symbolische Links erstellen)

Hardlinks und Softlinks in Linux erklärt

Echo To File Descriptor überschreibt die Datei?

Was sind symbolische Links in Linux? Wie erstellt man symbolische Links?

Jenkins tot, aber PID-Datei existiert

<Dienstname> tot, aber PID-Datei existiert