Les liens symboliques sont quasi universels sous Linux, mais ils n'existent nulle part ailleurs (sauf sur Cygwin qui les émule). existent également sur AIX et Solaris, mais ce ne sont pas des liens symboliques. Portablement, pour obtenir des informations sur les fichiers ouverts, installez ./proc/PID/fd/NUM
/proc/PID/fd/NUM
lsof
Unités avec /proc/PID/fd
Sous Linux, est un lien symbolique légèrement magique vers le fichier que le processus avec l'ID PID a ouvert sur le descripteur de fichier NUM . Ce lien est magique dans la mesure où, par exemple, il peut être utilisé pour accéder au fichier même si le fichier est supprimé. Le lien suivra également le fichier via des renommages. est un lien symbolique magique qui indique où PID est le processus qui accède au lien./proc/PID/fd/NUM
/proc/self
/proc/PID
Cette fonctionnalité est présente sur pratiquement tous les systèmes Linux. Il est fourni par le pilote du système de fichiers proc , qui est techniquement facultatif mais utilisé pour tant de choses (y compris pour faire le ps
travail - il lit ) qu'il n'est presque jamais laissé de côté, même sur les systèmes embarqués./proc/PID
Cygwin
Cygwin émule Linux (pour les processus Cygwin) et ./proc/PID/fd/NUM
/proc/self
Solaris (depuis la version 2.6), AIX
Il existe des entrées pour chaque descripteur de fichier, mais elles apparaissent comme le même type que le fichier ouvert, elles ne fournissent donc aucune information sur le chemin d'accès du fichier. Cependant, ils rapportent les mêmes informations que dans le cas du processus qui a ouvert le fichier, il est donc possible de déterminer sur quel système de fichiers se trouve le fichier et son numéro d'inode. Les répertoires apparaissent sous forme de liens symboliques, mais ce sont des liens symboliques magiques qui ne peuvent être suivis, et renvoie une chaîne vide./proc/PID/fd
stat
fstat
readlink
Sous AIX, la procfiles
commande affiche des informations sur les fichiers ouverts d'un processus. Sous Solaris, la pfiles
commande affiche des informations sur les fichiers ouverts d'un processus. Cela n'inclut pas le chemin d'accès au fichier (sur Solaris, il le fait depuis Solaris 10, voir ci-dessous).
De plus , les versions modernes de Solaris contiennent des liens symboliques similaires aux liens symboliques de Linux dans . La commande affiche des informations sur les fichiers ouverts d'un processus, y compris les chemins d'accès./proc/PID/fd/NUM
/proc/PID/path/NUM
/proc/PID/fd/NUM
pfiles
/proc/PID/fd
est un fichier texte qui contient un enregistrement (ligne) par descripteur de fichier ouvert par le processus. Le nom de fichier n'y est pas suivi.
/proc/PID/
est un répertoire, mais il ne contient aucune information sur les descripteurs de fichiers.
Unités avec /proc
mais pas d'accès direct aux descripteurs de fichiers
(Remarque: il est parfois possible d'obtenir des informations sur les fichiers ouverts d'un processus en parcourant son image mémoire qui est accessible sous /proc
. Je ne compte pas comme un "accès direct".)
Unices où se trouve un fichier/proc/PID
Le système de fichiers proc lui-même a commencé dans UNIX 8th edition, mais avec une structure différente, et est passé par Plan 9 et est revenu à certains unices. Je pense que tous les systèmes d'exploitation avec un /proc
ont une entrée pour chaque PID, mais sur de nombreux systèmes, c'est un fichier normal, pas un répertoire. Les systèmes suivants ont un qui doit être lu avec :/proc/PID
ioctl
- Solaris jusqu'à 2,5
- OSF / 1 maintenant connu sous le nom de Tru64
- IRIX (?)
- SCO (?)
MINIX 3 possède un serveur procfs qui fournit plusieurs composants de type Linux, y compris des répertoires. Mais ce n'est pas le cas ./proc/PID/
/proc/PID/fd
FreeBSD a des répertoires, mais ils ne fournissent pas d'informations sur les descripteurs de fichiers ouverts. (Il y a cependant qui est similaire à Linux , donnant accès à l'exécutable via un lien symbolique.)/proc/PID/
/proc/PID/file
/proc/PID/exe
Les procfs de FreeBSD sont obsolètes .
Unices sans /proc
- HP-UX
- OpenBSD
- NetBSD
- Mac OS X
Informations sur le descripteur de fichier via d'autres canaux
La fuser
commande répertorie les processus qui ont un fichier spécifié ouvert ou un fichier ouvert sur le point de montage spécifié. Cette commande est standard (disponible sur tous les systèmes compatibles XSI , c'est-à-dire POSIX avec l'extension d'interface système X / Open).
Vous ne pouvez pas passer d'un processus à des noms de fichiers avec cet utilitaire.
Lsof signifie «liste des fichiers ouverts». Il s'agit d'un outil tiers , disponible (mais ne fait généralement pas partie de l'installation par défaut) pour la plupart des variantes Unix. L'obtention d'informations sur les fichiers ouverts est très dépendante du système, car l'analyse ci-dessus pourrait vous faire suspecter. Le mainteneur lsof a fait le travail de tout combiner sous une seule interface.
Vous pouvez lire la FAQ pour voir quels types de difficultés lsof doit supporter. Sur la plupart des unités, l'obtention d'informations sur les noms des fichiers ouverts nécessite l'analyse des structures de données du noyau. Citant la FAQ 3.3 «Pourquoi lsof ne rapporte-t-il pas les noms de chemin complets?»:
Lsof ne peut pas obtenir les composants de nom de chemin à partir des caches de noms de noyau des dialectes suivants:
Seul le noyau Linux enregistre les noms de chemin complets dans les structures qu'il gère sur les fichiers ouverts; à la place, la plupart des noyaux convertissent les noms de chemin en doublons de numéros de périphérique et de nœud et les utilisent pour les références de fichier suivantes une fois les fichiers ouverts.
Si vous devez analyser les informations de lsof
la sortie de, assurez-vous d'utiliser le -F
mode (un champ par ligne), de préférence le -F0
mode (champs délimités par des valeurs nulles). Pour obtenir des informations sur un descripteur de fichier spécifique d'un processus spécifique, utilisez l' -a
option avec et , par exemple .-p PID
-d NUM
lsof -a -p 123 -d 0 -F0n
/dev/fd/NUM
pour les descripteurs de fichiers du processus en cours
De nombreuses variantes Unix permettent à un processus d'accéder à ses fichiers ouverts via un nom de fichier: ouvrir équivaut à appeler . Ces noms sont utiles lorsqu'un programme veut un nom de fichier mais que vous voulez passer un fichier déjà ouvert (par exemple un tube ou une socket); par exemple, les shells qui implémentent la substitution de processus les utilisent lorsqu'ils sont disponibles (en utilisant un canal nommé temporaire où il n'est pas disponible)./dev/fd/NUM
dup(NUM)
/dev/fd
Là où il /dev/fd
existe, il y a aussi généralement (toujours?) Des synonymes (parfois des liens symboliques, parfois des liens durs, parfois des fichiers magiques avec des propriétés équivalentes) /dev/stdin
= /dev/fd/0
, /dev/stdout
= /dev/fd/1
, /dev/stderr
= /dev/fd/2
.
- Sous Linux,
/dev/fd
est un lien symbolique vers /proc/self/fd
.
- Sous la plupart des unités ( IRIX , OpenBSD , NetBSD , SCO, Solaris ,…), les entrées dans
/dev/fd
sont des périphériques de caractères. Ils apparaissent généralement si le descripteur de fichier est ouvert ou non, et les entrées peuvent ne pas être disponibles pour les descripteurs de fichier au-dessus d'un certain nombre.
- Sous FreeBSD et OSX, le système de fichiers fdescfs fournit un
/dev/fd
répertoire dynamique qui suit les descripteurs ouverts du processus appelant. Une statique /dev/fd
est disponible /dev/fd
n'est pas montée.
- Sous OSF / 1 (Tru64),
/dev/fd
est fourni via fdfs .
- Il n'y en a pas
/dev/fd
sur AIX ou HP-UX.
pfiles
commande affiche le chemin des descripteurs de fichier. Il récupère ces informations du/proc/<pid>/path
répertoire que vous pourriez également mentionner. Voir docs.oracle.com/cd/E19253-01/817-0547/esxiq/index.html