Content-type: text/html
AIX 4.3.[23], 5L, and 5.1
Apple Darwin 1.[23] et 1.4 pour les systèmes Power
Macintosh
BSDI BSD/OS 4.1 pour les systèmes à base de
processeurs Intel
DEC OSF/1, Digital UNIX, Tru64 UNIX 4.0 et 5.[01]
FreeBSD 4.[234] et 5.0 pour les systèmes à base de
processeurs Intel
HP-UX 11.00 et 11.11
Linux 2.1.72 et supérieur pour les systèmes à base
de processeurs Intel
NetBSD 1.5 pour les systèmes basés Alpha, Intel
et SPARC
NEXTSTEP 3.[13] pour les architectures NEXTSTEP
OpenBSD 2.[89] and 3.0 pour les systèmes à base de
processeurs Intel
OPENSTEP 4.x
Caldera OpenUNIX 8
SCO OpenServer version 5.0.[46] pour les systèmes
à base de processeurs Intel
SCO UnixWare 7.1.1 pour les systèmes à base de
processeurs Intel
Solaris 2.6, 7, 8, et 9 BETA
(Voyez la section DISTRIBUTION de cette page de manuel pour savoir comment obtenir la dernière version de lsof ).
Un fichier ouvert peut être un fichier régulier, un répertoire, un fichier spécial en mode bloc, un fichier spécial en mode caractère, une référence de texte exécutable, une librairie, un flux ou un fichier réseau (socket Internet, fichier NFS ou socket de domaine UNIX). Un fichier spécifique ou tous les fichiers d'un système de fichiers peuvent être sélectionnés en spécifiant son (leur) chemin(s).
Au lieu d'un affichage formaté, lsof produira une sortie pouvant être analysée par d'autres programmes. Voyez la description de l'option -F, et la section SORTIE POUR D'AUTRES PROGRAMMES pour plus d'informations.
En plus de produire en sortie une liste unique, lsof s'exécutera en mode répétition. En mode répétition, il produira une sortie, attendra un moment, et répétera ensuite l'opération de sortie jusqu'à ce qu'il soit arrêté par un signal d'interruption ou d'arrêt. Voyez la description de l'option +|-r [t] pour plus d'informations.
Si une option de requête de liste est spécifiée, les autres requêtes de liste doivent être requises explicitement - p.ex., si -U est spécifié pour le listage des fichiers de sockets UNIX, les fichiers NFS ne seront pas listés à moins que -N ne soit également spécifié ; de façon similaire, si une liste d'utilisateurs est spécifiée avec l'option -u , les fichiers de sockets de domaine UNIX appartenant à des utilisateurs non présents dans la liste ne seront pas listés à moins que l'option -U ne soit également spécifiée.
Normalement, les options de listes qui sont explicitement indiquées sont associées par un OU - c.-à-d. que la spécification de l'option -i sans adresse et l'option -ufoo produisent un listing de tous les fichiers réseau OU appartenant à l'utilisateur « foo ». Une exception est le nom de connexion (login) « ^ » (nié) ou l'ID d'utilisateur (UID) spécifié avec l'option -u. Puisque c'est une exclusion, elle est appliquée sans réaliser de disjonction ni de conjonction et prend effet avant que tout autre critère de sélection ne soit appliqué.
L'option -a peut être utilisée pour préciser une conjonction (ET) de sélections. Par exemple, spécifier -a, -U et -ufoo produit un listing des seuls fichiers de socket UNIX qui appartiennent à des processus relevant de l'utilisateur « foo ».
Attention : l'option -a provoque la mise en association de toutes les options de sélection de liste par un ET binaire ; elle ne peut être utilisée pour effectuer une conjonction de paires sélectionnées d'options de sélection en étant placée entre elles, même si son emplacement est acceptable. À chaque fois que -a est utilisée, elle provoque la mise en conjonction de toutes les options de sélection.
Les éléments du même groupe de sélection - noms de commandes, descripteurs de fichiers, adresses réseau, identificateurs de processus, identificateurs d'utilisateurs - sont associés dans un seul ensemble par un OU binaire, et sont appliqués avant que le résultat ne participe à un ET binaire. Ainsi, par exemple, spécifier -i@aaa.bbb, -i@ccc.ddd, -a et -ufff,ggg sélectionnera le listing des fichiers qui appartiennent à « fff » OU à « ggg » ET qui disposent de connexions réseau vers l'hôte aaa.bbb OU ccc.ddd.
Les options peuvent être regroupées à la suite d'un préfixe unique -- p.ex., le jeu d'options « -a -b -C » peut être désigné par -abC. Néanmoins, puisque les valeurs suivant +|-f, -F, -g, -i, +|-L, -o, +|-r, -S ou -T sont optionnelles, si vous ne leur fournissez pas de valeur, prenez garde à ce que le caractère suivant ne soit pas ambigu. Par exemple, -Fn pourrait représenter les options -F et -n , ou pourrait représenter le n -ième identificateur de champ suivant l'option -F. Quand une ambiguïté est possible, faites débuter une nouvelle option par un caractère « - », p.ex. « -F -n ». Si l'option suivante est un nom de fichier, faites suivre l'option hypothétiquement ambiguë par « -- », p.ex. « -F -- nom ».
Le préfixe « + » ou « - » peut être appliqué à un groupe d'options. Les options qui n'ont pas une signification spéciale pour chaque préfixe - p.ex. -i - peuvent être groupées à la suite de l'un quelconque des préfixes. Par conséquent, par exemple, « +M -i » peut être indiqué sous la forme « +Mi » et le groupe signifie la même chose que les options séparées. Faites attention au groupement d'options quand une ou plusieurs des options du groupe prennent un signification différente en fonction du préfixe - p.ex, +|-M; « -iM » n'est pas la même requête que «-i +MM ». En cas de doute, utilisez des options séparées avec des préfixes appropriés.
b l'expression régulière est basique.
i ignorer la casse des lettres.
x l'expression régulière est étendue
(défaut).
? - rapporter les chemins de fichier de cache de
périphériques
b - construire le fichier de cache de périphériques
i - ignorer le fichier de cache de périphériques
r - lire le fichier de cache de périphériques
u - lire et mettre à jour le fichier de cache de
périphériques
$ lsof +f -- /nom/système/fichiers
c compteur d'utilisation de la structure
fichier
f adresse de la structure fichier
g abréviations des attributs de fichier
G attributs fichier en hexadécimal
n adresse de noeud de la structure fichier
46 spécifie la version IP, IPv4 ou IPv6
qui s'applique aux adresses à la suite.
« 6 » ne peut être spécifié que si le
dialecte UNIX supporte IPv6. Si ni « 4 » ni
« 6 » n'est spécifié, l'adresse à la suite
s'applique à toutes les versions d'IP.
protocole est un nom de protocole - TCP ou UDP.
nom_hôte est un nom d'hôte Internet. À moins qu'une
version IP spécifique ne soit spécifiée, les
fichiers réseau ouverts associés à des noms d'hôte
de toutes les versions seront sélectionnés.
adresse_hôte est une adresse IPv4 numérique en
notation décimale pointée, ou une adresse IPv6
numérique sous la forme double-pointée, enfermée
entre crochets, si le dialecte UNIX supporte IPv6.
Quand une version IP est sélectionnée, seules ses
adresses numériques peuvent être spécifiées.
service est un nom provenant de /etc/services
- p.ex. smtp - ou une liste de noms.
port est un numéro ou une liste de numéros de ports.
-i6 - IPv6 uniquement
TCP:25 - TCP et port 25
@1.2.3.4 - adresse d'hôte Internet IPv4 1.2.3.4
@[3ffe:1ebc::1]:1234 - adresse d'hôte Internet IPv6 3ffe:1ebc::1, port 1234
UDP:who - port du service UDP who
TCP@vic.cc:513 - TCP, port 513 et nom d'hôte vic.cc
tcp@foo:1-10,smtp,99 - TCP, ports 1 à 10, nom de service smtp, port 99, nom d'hôte foo
tcp@bar:smtp-serveur_de_noms - TCP, ports smtp jusqu'à serveur_de_noms, hôte bar
:time - le port de service d'horloge TCP ou UDP
-o -o 10
ou
-oo10
<nom état TCP ou TPI>
QR=<longueur queue lecture>
QS=<longueur queue émission>
WR=<longueur fenêtre de lecture> (pas tous
les dialectes)
WW=<longueur fenêtre d'écriture> (pas tous
les dialectes)
q sélectionne un rapport sur la longueur
de la queue.
s sélectionne un rapport sur l'état.
w sélectionne un rapport sur la taille de
fenêtre (pas sur tous les dialectes).
AIX 4.1.4 (AFS 3.4a)
HP-UX 9.0.5 (AFS 3.4a)
Linux 1.2.13 (AFS 3.3)
Solaris 2.[56] (AFS 3.4a)
Il peut reconnaître les fichiers AFS sur d'autres versions de ces dialectes, mais cela n'a pas été testé. En fonction de la façon dont AFS est implémenté, lsof peut reconnaître les fichiers AFS dans d'autres dialectes, ou avoir des difficultés à reconnaître les fichiers AFS dans les dialectes supportés.
Lsof peut avoir du mal à identifier tous les aspects des fichiers AFS dans les dialectes supportés quand le support noyau de l'AFS est implémenté via des modules dynamiques dont les adresses n'apparaissent pas dans la liste des noms de variables du noyau. Dans ce cas, lsof pourrait être dans l'obligation de deviner l'identité des fichiers AFS, et ne pas être capable d'obtenir depuis le noyau l'information de volume qui est nécessaire pour le calcul des numéros de noeuds de volumes AFS. Quand lsof ne peut calculer les numéros de noeuds de volume, il rapporte un blanc dans la colonne NODE (noeud).
L'option -A A est disponible sur certaines implémentations de dialectes de lsof pour spécifier le fichier de liste de noms où l'on peut trouver les adresses noyau des modules dynamiques. Quand cette option est disponible, elle sera listée dans la sortie d'aide de lsof , présentée en réponse au -h ou au -?
Voyez la FAQ lsof (La section FAQ vous donne son emplacement) pour obtenir plus d'informations sur les modules dynamiques, leurs symboles, et la façon dont ils affectent les options de lsof.
Puisque les recherches de chemin AFS ne semblent pas contribuer aux opérations du cache de noms du noyau, lsof ne peut identifier les composants du nom de chemin pour les fichiers AFS.
Le restriction sur le listage des fichiers ouverts est contrôlée par l'option de compilation HASSECURITY. Quand HASSECURITY est définie, lsof ne permettra qu'au seul root de lister tous les fichiers ouverts. L'utilisateur non root ne peut lister que les fichiers ouverts par les processus possédant le même numéro d'IDentification d'utilisateur que celui du numéro d'ID d'utilisateur du processus lsof (celui avec lequel l'utilisateur s'est connecté). Quand HASSECURITY n'est pas définie, n'importe qui peut lister tous les fichiers ouverts.
La sortie d'aide, présentée en réponse à l'option -h ou -? , fournit l'état de définition de la macro HASSECURITY.
Voyez la section Security du fichier 0README de la distribution de lsof pour savoir comment construire lsof en activant l'option HASSECURITY.
La création et l'utilisation d'un fichier de cache de périphériques accessible à la fois en lecture et en écriture par un utilisateur sont contrôlées par l'option de compilation HASDCACHE. Voyez la section FICHIER DE CACHE DE PÉRIPHÉRIQUE et suivantes pour connaître les détails de la formation du chemin. Pour des considerations de sécurité, il est important de noter que dans la distribution par défaut de lsof , si l'ID d'utilisateur réel sous lequel lsof est exécuté est root, le fichier de cache de périphérique sera écrit dans le répertoire personnel de root - c.-à-d. / ou /root. Quand HASDCACHE n'est pas définie, lsof n'essaie ni d'écrire ni de lire un fichier de cache de périphérique.
Quand HASDCACHE est définie, la sortie d'aide de lsof , présentée en réponse aux options -h, -D?, ou -? , fournira de l'information sur le traitement des fichiers de cache de périphérique. Quand HASDCACHE n'est pas définie, la sortie de -h ou de -? ne présentera pas la description de l'option -D.
Avant que vous ne décidiez de désactiver la fonctionnalité des fichiers de cache de périphérique - l'autoriser améliore la performance de lsof en réduisant la surcharge au démarrage induite par l'examen de tous les noeuds de /dev (ou /devices) - lisez la discussion à ce sujet dans le fichier 00DCACHE de la distribution de lsof et la FAQ lsof (La section FAQ vous donne son emplacement.)
EN CAS DE DOUTE, VOUS POUVEZ DÉSACTIVER TEMPORAIREMENT L'UTILISATION DU FICHIER DE CACHE DE PÉRIPHÉRIQUES AVEC L'OPTION -Di.
Quand l'utilisateur de lsof déclare des listes de noms du noyau ou des fichiers mémoire alternatifs avec les options -k et -m , lsof vérifie que l'utilisateur à l'autorisation de les lire avec access(2). C'est destiné à éviter les pouvoirs spéciaux que les modes de lsof pourraient lui conférer en lui laissant lire des fichiers normalement non accessibles d'après les droits de l'ID de l'utilisateur réel.
Lsof ne produit que des caractères ASCII imprimables (considérés comme tels par isprint(3)). Les caractères non imprimables sont affichés dans l'une des trois formes suivantes : la forme C « \[bfrnt] » ; la forme caractère de contrôle « ^ » (p.ex. « ^@ ») ; ou la forme hexadécimale avec un « \x » de tête (p.ex. « \xab »). L'espace est non imprimable dans la colonne COMMAND (« \x20 ») et imprimable ailleurs.
Lsof dimensionne dynamiquement les colonnes de sortie à chaque fois qu'il est exécuté, en garantissant que chaque colonne ait une taille minimale. Il garantit aussi que chaque colonne est séparée de la précédente par au moins une espace.
cwd répertoire de travail actuel ;
Lnn références de librairie (AIX) ;
jld répertoire « prison » (FreeBSD) ;
ltx texte de librairie partagée (code et données) ;
Mxx HEX MEMORY-MAPPED TYPE NUMBER xx.
m86 DOS MERGE MAPPED FILE ;
mem fichier projeté en mémoire ;
mmap périphérique projeté en mémoire ;
pd répertoire parent ;
rtd répertoire racine ;
txt texte du programme (code et données) ;
v86 VP/ix MAPPED FILE ;
AIO E/S asynchrone (p.ex. FAIO)
AP concaténation
ASYN E/S asynchrone (p.ex. FASYNC)
BAS BLOCK, TEST, AND SET IN USE
BKIU BLOCK IF IN USE
BL utiliser les décalages de blocs
BSK recherche de bloc
CA évitement de copie
CLON clone
CLRD CL READ
CR créer
DF différer
DFI différer IND
DFLU vidage de données
DIR DIRECTz(quelle traduction?)
DLY délai
DOCL créer un clone
DSYN intégrité des données uniquement
EX ouverture pour exec
EXCL ouverture exclusive
FSYN écritures synchrones
GCDF différer pendant unp_gc() (AIX)
GCMK marquer pendant unp_gc() (AIX)
GTTY accédé via /dev/tty
HUP HUP en cours
KERN noyau
KIOC ioctl émis du noyau
LCK possède un verrou
LG gros fichier
MBLK bloc de message de flux
MK marqué
MNT monté
MSYN synchronisation multiplexée
NB E/S non bloquantes
NBDR pas de contrôle BDRM
NBIO E/S SYSV non bloquantes
NBF n-buffering en cours
NC pas de cache
ND pas de délai
NDSY pas de synchronisation des données
NET réseau
NMFS système de fichiers NM
NOTO DISABLE BACKGROUND STOP
NSH aucun partage
NTTY aucun TTY de contrôle
OLRM miroir OLR
PAIO E/S POSIX asynchrones
PP tube POSIX
R READ
RAIO requête RAIO sur Reliant UNIX
RC cache de verrouillage de fichier et d'enregistrement
REV révoqué
RSH lecture partagée
RSYN synchronisation en lecture
SL verrou partagé
SOCK socket
SQSH Sequent SHARED SET ON OPEN(Sequent:type de machine non?)
SQSV Sequent SVM SET ON OPEN
SQR Sequent SET REPAIR ON OPEN
SQS1 Sequent FULL SHARED OPEN
SQS2 Sequent PARTIAL SHARED OPEN
STPI arrêter les E/S
SWR SYNCHROUNOUS READ (rem:ça serait pas écriture plutôt? Synchro WRite)
SYN intégrité du fichier lors de l'écriture
TCPM éviter les collision TCP
TR tronquer
W écrire
WKUP synchronisation I/O parallèles
WTG synchronisation I/O parallèles
VH vhangup en attente
VTXT texte virtuel
XL verrou exclusif
ALLC alloué
BR le fichier a été lu
BHUP activité stoppée par SIGHUP
BW le fichier a été écrit
CLSG fermeture
CX close-on-exec (voir fcntl(F_SETFD))
MP projeté en mémoire
LCK verrou appliqué
RSVW attente réservée
SHMT ensemble UF_FSHMAT (AIX)
USE en cours d'utilisation (multi-threadé)
Pour les dialectes qui supportent un système de fichiers « namefs », permettant à un fichier d'être attaché à un autre avec fattach(3C), lsof ajoutera « (FA:<adresse1><direction><adresse2>) » dans la colonne NAME. <adresse1> et <adresse2> sont des adresses de v-noeuds hexadécimales. <direction> sera « <- » si <adresse2> a été fattach-ée à ce v-noeud dont l'adresse est <adresse1> ; et « -> » si <adresse1>, l'adresse de v-noeud de ce v-noeud, a été fattach-ée à <adresse2>. <adresse1> peut être omise si elle apparaît déjà dans la colonne DEVICE.
Qui plus est, quand un processus détient plusieurs verrous au niveau octet sur un fichier, lsof ne rapporte que le statut du premier verrou rencontré. S'il s'agit d'un verrou au niveau octet, alors le caractère de verrouillage sera rapporté en minuscule - c.-à-d. « r », « w » ou « x » - plutôt que la majuscule équivalente rapportée pour un verrou de fichier entier.
Généralement, lsof ne peux rapporter que les verrous détenus par des processus locaux sur des fichiers locaux. Quand un processus local pose un verrou sur un fichier monté à distance (p.ex. via NFS), l'hôte serveur distant enregistre habituellement l'état du verrou. Solaris forme une exception - pour certains niveaux de patch des version 2.3, et dans toutes les version supérieures à 2.4, le noyau Solaris enregistre de l'information sur les verrous distants dans des structures locales.
Lsof a du mal à rapporter les verrous pour certains dialectes UNIX. Consultez la section BOGUES de cette page de manuel ou la FAQ lsof (La section FAQ vous donne son emplacement.) pour plus d'informations.
Chaque unité d'information est produite en sortie dans un champ qui est identifié par un caractère de tête et qui est terminé par un NL (012) (ou un NUL (000) si le caractère identificateur de champ 0 (zéro) est spécifié.) Les données du champ suivent immédiatement le caractères d'identification de champ et s'étendent jusqu'au terminateur de champ.
Il est possible de se représenter la sortie en champs comme des ensembles de processus et de fichiers. Un ensemble de processus commence par un champ dont l'identificateur est « p » (pour IDentificateur de processus)). Il s'étend jusqu'au commencement du champ de PID suivant ou jusqu'au début du premier ensemble de fichiers du processus, celui qui vient en premier. Sont également inclus dans l'ensemble de fichiers : les champs qui identifient la commande, le numéro d'IDentification de Groupe de Processus (PGID), et le numéro d'ID d'utilisateur (UID) ou nom de connexion.
Un ensemble de fichiers commence par un champ dont l'identificateur est « f » (pour descripteur de fichier). Il est suivi de lignes décrivant les modes d'accès, état de verrouillage, type, périphérique, taille, offset, i-noeud, protocole et nom du fichier, et les noms des modules de flux. Il s'étend jusqu'au début de l'ensemble de fichiers ou de processus suivant, à savoir celui vient en premier.
Quand le terminateur de champ NUL (000) a été sélectionné avec le caractère identificateur de champ 0 (zéro), lsof termine chaque ensemble de processus et de fichiers par un caractère NL (012).
Lsof produit toujours un champ, le champ PID (« p »). Tous les autres champs peuvent être déclarés facultativement dans la liste de caractères identificateurs de champ qui suit l'option -F. Quand un caractère de sélection de champ identifie un élément que ne liste normalement pas lsof - p.ex. le PPID, sélectionné avec la spécification -R - de caractère de champ - p.ex. « -FR » - sélectionne également le listage de l'élément.
Il est parfaitement possible de sélectionner un groupe de champs qui ne peuvent aisément être analysé - p.ex. si le champ de descripteur de champ n'est pas sélectionné, il peut être difficile d'identifier les ensembles de fichiers. Pour vous aider à éviter cet obstacle, lsof supporte l'option -F ; elle sélectionne la sortie de tous les champs de terminateur NL (le couple d'options -F0 sélectionne la sortie de tous les champs de terminateur NUL). Pour des raisons de compatibilité, ni -F ni -F0 ne sélectionnent le champ raw device.
Voici les champs que produira lsof. Le caractère unique listé en premier lieu est l'identificateur de champ.
a mode d'accès du fichier
c nom de commande du processus (tous les caractères provenant de
proc ou d'une structure utilisateur)
C nombre de partages de la structure fichier
d code de caractère du périphérique du fichier
D numéro de périphérique majeur/mineur (0x<hexadécimal>)
f descripteur du fichier
F adresse de la structure fichier (0x<hexadécimal>)
G attributs du fichier (0x<hexadécimal> ; NAMES(la commande?) si suivi de +fg)
i numéro d'i-noeud du fichier
l état de verrouillage du fichier
L nom de l'utilisateur exécutant le processus
m marqueur entre des sorties répétées
n nom du fichier, commentaire, adresse Internet
N identificateur de noeud (ox<hexadécimal>
o position dans le fichier (décimal)
p ID du processus (toujours sélectionné)
g ID du groupe de processus
P nom du protocole
r numéro de périphérique brut (0x<hexadécimal>)
R ID du processus père
s taille du fichier (décimale)
S identification du flux du fichier
t type du fichier
T information TCP/TPI, identifiée par des préfixes (le
« = » fait partie du préfixe) :
ST=<état>
QR=<taille queue de lecture>
QS=<taille queue de écriture>
WR=<taille fenêtre de lecture> (pas tous les dialectes)
WW=<taille fenêtre d'écriture> (pas tous les dialectes)
(L'information d'état TPI et les tailles de fenêtre ne sont pas
rapportées sur tous les dialectes UNIX supportés.
La sortie d'aide -h ou -? pour l'option -T montrera si on peut
requérir le rapportage de la taille de fenêtre.)
u ID utilisateur du processus
0 utiliser le caractère de terminaison de champ NUL plutôt que NL
1-9 identificateurs de champs spécifiques au dialecte (La sortie
de -F? identifie l'information que l'on peut trouver
dans les champs spécifiques au dialecte.)
Vous pouvez obtenir de l'information en ligne sur ces caractères et leur description en spécifiant le couple d'options -F? (Protégez le caractère « ? » si votre shell le requiert.) Des informations supplémentaires sur le contenu des champs peuvent être trouvées dans la section SORTIE.
Par exemple, « -F pcfn » sélectionnera les champs ID de processus (« p »), nom de commande (« c »), descripteur de fichier (« f ») et le nom de fichier (« n ») avec NL servant comme caractère terminateur de champ ; « -F pcfn0 » sélectionne la même sortie mais avec NUL (000) comme caractère terminateur de champ.
Lsof ne produit pas tous les champs pour chaque ensemble de processus ou de fichiers, mais uniquement ceux qui sont disponibles. Certains champs sont mutuellement exclusifs : les caractères de périphérique de fichier et les numéros de périphérique majeur/mineur ; numéro d'i-noeud du fichier et nom de protocole ; nom du fichier et identification du flux ; taille du fichier et position. Un seul membre de ces ensembles mutuellement exclusifs apparaîtra dans la sortie des champs, mais pas les deux.
Normalement, lsof termine chaque champ par un caractère NL (012). Le caractère identificateur de champ 0 (zéro) peut être spécifié pour remplacer le caractère terminateur de champ par un NUL (000). Un terminateur NUL peut être plus facile à traiter avec xargs (1), par exemple, ou avec des programmes dont les mécanismes de protection ne peuvent facilement gérer l'intervalle de caractères dans la sortie en champs. Quand le terminateur de champ NUL est utilisé, lsof termine chaque ensemble de processus et de fichiers par un NL (012).
Deux aides à la production de programmes pouvant traiter la sortie en champs de lsof sont incluses dans la distribution de lsof. La première est un fichier d'en-tête, lsof_fields.h, qui contient des symboles pour les caractères d'identification de champs, des index pour les stocker dans une table, et des chaînes de caractères d'explication qui peuvent être compilées dans les programmes. Lsof utilise ce fichier d'en-tête.
La seconde aide et un jeu de scripts d'exemples qui traitent la sortie en champs, qui sont écrits en awk, Perl 4, et Perl 5. Ils sont situés dans le sous-répertoire scripts de la distribution de lsof.
Lsof essaie de se dégager de ces blocages grâce à des temporisateurs et des processus enfants, mais les techniques ne sont pas entièrement fiables. Quand lsof arrive à se dégager d'un blocage, il rapportera ce blocage par un message d'erreur. Les messages peuvent être supprimés avec les options -t et -w.
La valeur de temporisation par défaut peut être affichée avec l'option -h ou -? , et peut être modifiée avec l'option -S [t]. Le minimum pour t est deux secondes, mais vous devriez éviter de faibles valeurs, car le temps de réponse de systèmes lents peut provoquer l'expiration de temporisateurs de façon inattendue et peut-être stopper lsof avant qu'il n'ait pu produire quoi que ce soit en sortie.
Quand lsof doit se dégager d'un blocage pendant un accès à de l'information sur le système de fichiers monté, il continue normalement, bien que disposant de moins d'information disponible à afficher sur les fichiers ouverts.
Lsof peut également être enjoint à éviter la protection des temporisateurs et des processus enfants quand il utilise des fonctions du noyau qui pourraient bloquer en spécifiant l'option -O. Bien que cela permette à lsof de démarrer avec une moins grande surcharge, cela expose complètement lsof aux situations de noyau qui pourraient le bloquer. Utilisez cette option avec précaution.
Vous pouvez utiliser l'option -b pour indiquer à lsof d'éviter d'utiliser les fonctions du noyau qui pourraient bloquer. Certaines précautions sont de mise.
D'abord, l'utilisation de cette option requiert habituellement que votre système fournisse des numéros de périphériques alternatifs en lieu et place des numéros de périphériques qu'obtiendrait normalement lsof via les fonctions du noyau lstat(2) et stat(2). Voyez la section NUMÉROS DE PÉRIPHÉRIQUES ALTERNATIFS pour en savoir plus sur les numéros de périphériques alternatifs.
Ensuite, vous ne pouvez spécifier de noms à faire localiser par lsof à moins qu'ils ne soient des noms de systèmes de fichiers. Cela est dû au fait que lsof doit connaître les numéros de périphérique et d'i-noeud des fichiers listés avec noms dans les options de lsof , et que l'option -b empêche lsof de les obtenir. De plus, puisque lsof ne dispose de numéro de périphériques que pour les systèmes de fichiers qui ont des alternatives, sa faculté à localiser des fichiers sur des systèmes de fichiers dépend entièrement de la disponibilité et de la précision des alternatives. Si aucune alternative n'est disponible, ou si elles sont incorrectes, lsof ne sera pas en mesure de localiser des fichiers sur les systèmes de fichiers nommés.
De plus, si les noms des répertoires de votre système de fichiers obtenus par lsof à partir de la table de montage de votre système sont des liens symboliques, lsof ne sera pas capable de résoudre les liens. Cela est dû au fait que l'option -b fait éviter à lsof l'utilisation de la fonction du noyau readlink(2) qu'il utilise pour résoudre les liens symboliques.
Finalement, l'utilisation de l'option -b fait émettre des messages d'avertissement à lsof quand il a besoin d'utiliser les fonctions du noyau que l'option -b lui ordonne d'éviter. Vous pouvez supprimer ces messages en spécifiant l'option -w , mais si vous le faites, vous ne verrez pas les numéros de périphériques alternatifs rapportés dans les messages d'avertissement.
Sur certains dialectes, quand lsof doit se dégager d'un blocage parce qu'il ne peut obtenir d'information sur un système de fichiers monté via les fonctions du noyau lstat(2) et stat(2) , ou parce que vous avez spécifié l'option -b , lsof peut obtenir certaines informations qu'il désire - le numéro de périphérique et peut-être le type du système de fichiers - à partir de la table de montage du système. Quand cela est possible, lsof rapportera le numéro de périphérique qu'il a obtenu. (Vous pouvez empêcher l'émission du rapport en spécifiant l'option -w.)
Vous pouvez favoriser ce processus si votre table de montage est supportée via un fichier /etc/mtab ou /etc/mnttab qui contient un champs d'options en ajoutant un champ « dev=xxxx » pour les points de montage qui n'en possèdent pas dans leur chaîne d'options.
La partie « xxxx » du champ est la valeur hexadécimale du numéro de périphérique du système de fichiers. (Consultez le champ st_dev de la sortie des fonctions lstat(2) et stat(2) pour obtenir les valeurs appropriées pour vos systèmes de fichiers.) Voici un exemple provenant d'un fichier /etc/mnttab sous Solaris 2.6 pour un système de fichiers monté à distance via NFS :
nfs ignore,noquota,dev=2a40001
Il y a un avantage à avoir des entrées « dev=xxxx » dans votre fichier de table de montage, spécialement pour les systèmes de fichiers qui sont montés à partir de serveurs NFS distants. Quand un serveur distant se crashe et que vous voulez identifier ses utilisateurs en exécutant lsof sur l'un de ses clients, lsof ne sera probablement pas capable d'obtenir la sortie des fonctions lstat(2) et stat(2) pour le système de fichiers. S'il peut obtenir le numéro de périphérique du système de fichiers à partir de la table de montage, il sera capable d'afficher les fichiers ouverts sur le serveur NFS crashé.
Quelques dialectes qui n'utilisent pas de fichier ASCII /etc/mtab ou /etc/mnttab pour la table de montage peuvent tout de même fournir un numéro de périphérique alternatif dans leurs tables de montage internes. Ils se composent de AIX, Apple Darwin, DEC OSF/1, Digital UNIX, FreeBSD, NetBSD, OpenBSD et Tru64 UNIX. Lsof sait comment obtenir le numéro de périphérique alternatif pour ces dialectes, et l'utilise quand sa tentative de lstat(2) ou stat(2) -er le système de fichiers est bloquée.
Si vous n'êtes pas certain que votre dialecte supporte les numéros de périphériques alternatifs pour les systèmes de fichiers présents dans sa table de montage, utilisez cette incantation de lsof pour voir si elle rapporte des numéros de périphériques alternatifs :
Recherchez parmi les messages d'avertissement concernant les fichiers sur la sortie d'erreur standard, ceux qui commencent par « assuming "dev=xxxx" from ... ».
Lsof est capable d'examiner le cache de noms du noyau ou d'utiliser d'autres mécanismes du noyau (p.ex. la fonction tag_to_path() ADVFS 4.x sous Digital UNIX ou Tru64 UNIX) sous certains dialectes pour la plupart des types de systèmes de fichiers, AFS exclus, et d'en extraire des composants de noms de chemin récemment utilisés. (Les recherches de chemin dans le système de fichiers AFS n'utilisent pas le cache de noms du noyau.)
Lsof rapporte les chemins complets qu'il trouve dans la colonne NAME. Si lsof ne peut rapporter tous les composants d'un chemin, il rapporte dans la colonne NAME le nom du système de fichiers, suivi par une espace, deux caractères « - », une autre espace, et les composants du nom qu'il a localisé, séparés par le caractère « / ».
Quand lsof est exécuté en mode répétition - c.-à-d. lorsque l'option -r est spécifiée - la faculté qu'il a à rapporter les composants de noms de chemin pour le même fichier peut varier de période en période. Cela est dû au fait que les autres processus s'exécutant peuvent faire supprimer par le noyau des entrées de son cache de noms et les remplacer par d'autres.
L'utilisation par lsof du cache de noms du noyau pour identifier les chemins des fichiers peut l'amener à rapporter incorrectement des composants dans certaines circonstances. Cela peut se produire quand le cache de noms du noyau utilise les numéros de périphérique et de noeud comme clé (p.ex. Linux et SCO OpenServer) et qu'une clé est réutilisée sur un systèmes de fichiers subissant des changements fréquents est réutilisée. Si le noyau du dialecte UNIX ne purge pas l'entrée d'un fichier du cache de noms quand il est supprimé, lsof peut trouver une référence vers la mauvaise entrée dans le cache. La FAQ lsof (La section FAQ vous donne son emplacement.) dispose de plus d'informations sur cette situation.
Lsof peut rapporter les composants de noms de chemin pour ces dialectes :
BSDI BSD/OS
DC/OSx
DEC OSF/1, Digital UNIX, Tru64 UNIX
FreeBSD
HP-UX
Linux
NetBSD
NEXTSTEP
OpenBSD
Reliant UNIX
Caldera OpenUNIX
SCO OpenServer
SCO UnixWare
Solaris
Lsof ne peut rapporter les composants de noms de chemin pour ces dialectes :
AIX
Si vous voulez savoir pourquoi lsof ne peut rapporter les composants de noms de chemin pour certains dialectes, voyez la FAQ lsof (La section FAQ vous donne son emplacement).
L'examen de tous les membres de l'arbre de noeuds /dev (ou /devices) avec les fonctions stat(2) peut prendre du temps. Qui plus est, l'information dont a besoin lsof - numéro de périphérique, numéro d'i-noeud, et chemin - change rarement.
Par conséquent, lsof maintient normalement un fichier texte ASCII servant de cache d'information sur /dev (ou /devices) (exception : les systèmes Linux utilisant le mécanisme /proc lsof où cela n'est pas nécessaire.) L'administrateur du système local qui construit lsof peut contrôler la façon dont le chemin du fichier de cache des périphériques est formé, en utilisant les possibilités suivantes :
Chemin provenant de l'option -D ;
Chemin provenant d'une variable d'environnement ;
Chemin global au système ;
Chemin personnel (défaut) ;
Chemin personnel, modifié par une variable
d'environnement.
Consultez la sortie des options d'aide -h, -D? ou -? pour obtenir l'état courant du support du cache des périphériques. La sortie d'aide liste le chemin du fichier de cache des périphériques en mode lecture par défaut qui est utilisé par l'invocation actuelle de lsof. La sortie de l'option -D? liste les chemins de fichiers de cache des périphériques dans les modes lecture seule et écriture, le nom de toutes les variables d'environnement pertinentes, et le format du fichier de cache des périphériques personnel.
Lsof peut détecter que le fichier de cache des périphériques actuel a été modifié accidentellement ou avec malveillance par des contrôles d'intégrité, qui incluent le calcul et la vérification d'une somme de Contrôle de Redondance Cyclique (CRC) de 16 bits sur le contenu du fichier. Quand lsof perçoit qu'il y a un problème avec le fichier, il émet un avertissement et essaie de supprimer le fichier de cache actuel et de créer une nouvelle copie, mais seulement dans un chemin où le processus peut légitimement écrire.
Le chemin à partir duquel un processus lsof peut essayer de lire un fichier de cache de périphériques ne peut pas être le même que le chemin dans lequel il peut légitimement écrire. Ainsi, quand lsof prend conscience qu'il doit mettre à jour le fichier de cache des périphériques, il peut choisir, pour l'écriture, un chemin différent de celui utilisé pour la lecture d'une version incorrecte ou périmée.
Si elle est disponible, l'option -Dr empêchera l'écriture d'un nouveau fichier de cache des périphériques. (Cela est toujours disponible quand c'est spécifié sans argument de nom de chemin.)
Quand un nouveau périphérique est ajouté au système, il se peut que le fichier de cache des périphériques doive être recréé. Puisque lsof compare le mtime du fichier de cache des périphériques avec les mtime et ctime du répertoire /dev (ou /devices) , il détecte habituellement qu'un nouveau périphérique a été ajouté ; dans ce cas, lsof émet un message d'avertissement et essaie de reconstruire le fichier de cache des périphériques.
À chaque fois que lsof écrit un fichier de cache des périphériques, il fixe sa propriété à l'UID réel du processus exécutant, et ses modes de permission à 0600, ne permettant ainsi la lecture et l'écriture que par le seul propriétaire du fichier.
Deux permissions de l'exécutable lsof affectent sa faculté à accéder aux fichiers de cache de périphériques. Les permissions sont établies par l'administrateur local quand lsof est installé.
La première permission et la plus rare est setuid-root. Elle entre en vigueur quand lsof est exécuté ; son UID effectif est alors root, alors que son UID réel (c.-à-d. celui de l'utilisateur connecté) ne l'est pas. La distribution de lsof recommande que les versions pour ces dialectes soient exécutées dans le mode setuid-root :
DC/OSx 1.1 pour les systèmes Pyramid
Reliant UNIX 5.4[34] pour les systèmes Pyramid
La seconde permission plus ordinaire est setgid. Elle entre en vigueur quand le numéro d'IDentification de Groupe (GID) effectif du processus lsof compte parmi ceux qui peuvent accéder aux périphériques mémoire du noyau - p.ex. « kmem », « sys » ou « system ».
Un processus lsof qui possède la permission setgid délaisse habituellement la permission après avoir accédé aux périphériques mémoire du noyau. Quand il fait cela, lsof peut permettre des formations de chemin de cache de périphériques plus permissives. La distribution de lsof recommande que les versions pour ces dialectes soient exécutées dans le mode setgid et délaissent leur permission setgid.
AIX 4.3.[23], 5L et 5.1
Apple Darwin 1.[23] et 1.4 pour les systèmes Power Macintosh
BSDI BSD/OS 4.1 pour les systèmes à base de processeurs Intel
DEC OSF/1, Digital UNIX, Tru64 UNIX 4.0 et 5.[01]
FreeBSD 4.[234] et 5.0 pour les systèmes à base de processeurs Intel
HP-UX 11.00
NetBSD 1.5 pour les systèmes d'architecture Alpha, Intel et SPARC
NEXTSTEP 3.[13] pour les architectures NEXTSTEP
OpenBSD 2.[89] et 3.0 pour les systèmes à base de processeurs Intel
Caldera OpenUNIX
SCO OpenServer Release 5.0.[46] pour les systèmes à base de processeurs Intel
SCO UnixWare 7.1.1 pour les systèmes à base de processeurs Intel
Solaris 2.6, 7, 8 et 9 BETA
(Note : lsof sous AIX 5L et supérieur a besoin de la permission setuid-root si l'option -X est utilisée.)
Lsof ne supporte pas de cache de périphériques pour les dialectes suivants, et les permissions ainsi données à l'exécutable ne s'appliquent pas au fichier de cache des périphériques.
Linux 2.1.72 et supérieur (lsof utilisant /proc)
L'option -D fournit des moyens limités de spécification du chemin du fichier de cache des périphériques. Sa fonction ? rapportera les chemins de fichiers de cache des périphériques dans les modes lecture seule et écriture qu'utilisera lsof.
Quand les fonctions -D b, r et u sont disponibles, vous pouvez les utiliser pour requérir que le fichier de cache soit construit dans un endroit spécifique (b[chemin]) ; lu mais non reconstruit (r[chemin]) ; ou lu et reconstruit (u[chemin]). Les fonctions b, r et u sont interdites dans certaines circonstances. Elles sont interdites quand le processus lsof s'exécute dans le mode setuid-root. Le chemin spécifié par l'option r est toujours accessible en lecture seule, même quand il est disponible.
Les fonctions b, r et u sont également interdites quand le processus lsof tourne dans le mode setgid et que lsof ne délaisse pas la permission setgid. (Voyez la section PERMISSIONS DE LSOF QUI AFFECTENT L'ACCÈS AU FICHIER DE CACHE DES PÉRIPHÉRIQUES pour une liste des implémentations qui ne délaissent normalement pas leur permission setgid.)
Une fonction supplémentaire de -D , à savoir i (pour ignorer), est toujours disponible.
Quand elle est disponible, la fonction b indique à lsof de lire de l'information sur un périphérique à partir du noyau avec la fonction stat(2) et de construire un fichier de cache des périphériques dans le chemin indiqué/
Quand elle est disponible, la fonction r indique à lsof de lire le fichier de cache des périphériques, mais de ne pas le mettre à jour. Quand un argument chemin accompagne -Dr, celui-ci nomme le chemin du fichier de cache des périphériques. La fonction r est toujours disponible quand elle est spécifiée sans argument de nom de chemin. Si lsof ne tourne pas dans le mode setuid-root et abandonne sa permission setgid, un argument de nom de chemin peut accompagner la fonction r.
Quand elle est disponible, la fonction u indique à lsof d'essayer de lire et d'utiliser le fichier de cache des périphériques. S'il ne peut pas lire le fichier, ou s'il juge que le contenu du fichier est incorrect ou périmé, il lira l'information à partir du noyau, et essaiera d'écrire une version mise à jour du fichier de cache des périphériques, mais uniquement dans un chemin qu'il considère comme légitime pour les UIDs effectif et réel du processus lsof.
Le second choix de lsof pour le fichier de cache des périphériques est le contenu de la variable d'environnement LSOFDEVCACHE. Il évite ce choix si le processus tourne dans le mode lsof setuid-root, ou si l'UID réel du processus est root.
Une restriction supplémentaire s'applique au fichier de cache des périphériques obtenu à partir de la variable d'environnement LSOFDEVCACHE : lsof n'écrira pas de fichier de cache de périphériques dans le chemin si le processus lsof ne délaisse pas sa permission setgid. (Voyez la section PERMISSIONS DE LSOF QUI AFFECTENT L'ACCÈS AU FICHIER DE CACHE DES PÉRIPHÉRIQUES pour une liste des implémentations qui ne délaissent pas leur permission setgid.)
L'administrateur du système local peut désactiver l'utilisation de la variable d'environnement LSOFDEVCACHE ou changer son nom lors de la construction de lsof. Consultez la sortie de -D? pour connaître le nom de la variable d'environnement.
L'administrateur du système local peut choisir d'avoir un fichier de cache des périphériques global lors de la construction de lsof. Le fichier sera généralement construit via une procédure d'administration spéciale du système lorsque le système est démarré ou quand le contenu de /dev ou /devices) change. S'il est défini, c'est le troisième choix chemin du fichier de cache des périphériques de lsof .
Vous pouvez savoir si un fichier de cache des périphériques global est en vigueur sur votre installation locale en examinant la sortie de l'option d'aide de lsof - c.-à-d. la sortie de l'option -h ou -?.
Lsof n'écrira jamais par défaut dans le fichier de cache des périphériques global. Il doit explicitement être nommé via une fonction -D dans une procédure appartenant à root. Une fois que le fichier a été écrit, la procédure doit remplacer ses modes de permission par 0644 (lecture et écriture par le propriétaire, lecture par le groupe, lecture pour les autres).
Le chemin du cache des périphériques par défaut de la distribution de lsof est enregistré dans le répertoire personnel de l'UID réel qui exécute lsof. On ajoute au répertoire personnel un second composant de chemin de la forme .lsof_nomhôte.
C'est le quatrième choix de lsof lors de la recherche du chemin du fichier de cache des périphériques, et est habituellement le défaut. Si un fichier de cache global des périphériques a été défini quand lsof a été construit, ce quatrième choix sera utilisé quand lsof ne trouve pas le fichier de cache global des périphériques. C'est la seule fois où lsof utilise deux chemins lors de la lecture du fichier de cache des périphériques.
La partie nomhôte du second composant est le nom de base de l'hôte exécutant, comme renvoyé par gethostname(2). Le nom de base est défini par les caractères précédant le premier « . » dans la sortie de gethostname(2) , ou toute la sortie de gethostname(2) si elle ne contient aucun « . ».
Le fichier de cache des périphériques global appartient à l'ID utilisateur et n'est accessible en lecture et écriture que par l'ID de l'utilisateur seul, c.-à-d. que ses modes sont 0600. Chaque ID utilisateur distinct sur un hôte donné qui exécute lsof possède un fichier de cache des périphériques distinct. La partie nomhôte du chemin permet de distinguer les fichiers de cache de périphériques d'un répertoire personnel monté via NFS dans lequel les fichiers de cache de périphériques sont écrits à partir d'hôtes différents.
Le fichier de cache des périphériques personnel formé par cette méthode représente un fichier de cache de périphériques que lsof essaiera de lire et d'écrire, qu'il existe ou pas, ou que son contenu soit incorrect ou périmé ou pas.
L'option -Dr sans un argument de nom de chemin empêchera l'écriture d'un nouveau fichier de cache de périphériques.
L'option -D? listera la spécification de format pour la construction du fichier de cache de périphériques personnel. Les conversions utilisées dans la spécification de format sont décrites dans le fichier 00DCACHE de la distribution de lsof.
Si cette option est définie par l'administrateur du système local quand lsof est construit, le contenu de la variable d'environnement LSOFPERSDCPATH peut être utilisé pour ajouter un composant du chemin du fichier de cache de périphériques personnel.
Le contenu de la variable d'environnement LSOFPERSDCPATH est inséré dans le chemin à l'endroit spécifié par l'administrateur du système local avec la conversion « %p » de la spécification de format HASPERSDC du fichier d'en-tête machine.h du dialecte. (Il est placé juste après le répertoire personnel dans la distribution par défaut de lsof .)
Ainsi, par exemple, si LSOFPERSDCPATH contient « LSOF », le répertoire personnel est « /Homes/abe », le nom d'hôte est « vic.cc.purdue.edu », et le format HASPERSDC est le défaut (« %h/%p.lsof_%L »), le chemin du fichier de cache de périphériques personnel modifié est :
/Homes/abe/LSOF/.lsof_vic
La variable d'environnement LSOFPERSDCPATH est ignorée quand le processus lsof tourne dans le mode setuid-root ou quand l'UID réel du processus est root.
Lsof n'écrira pas dans un chemin du fichier de cache de périphériques personnel modifié si le processus lsof ne délaisse pas sa permission setgid. (Voyez la section PERMISSIONS DE LSOF QUI AFFECTENT L'ACCÈS AU FICHIER DE CACHE DES PÉRIPHÉRIQUES pour une liste des implémentations qui ne délaissent normalement pas leur permission setgid.)
Si, par exemple, vous voulez créer un sous-répertoire de chemins de fichiers de cache de périphériques personnels en utilisant la variable d'environnement LSOFPERSDCPATH pour le nommer, et si lsof ne délaisse pas sa permission setgid, vous devrez permettre à lsof de créer des fichiers de cache de périphériques dans le chemin personnel standard, et ensuite les déplacer dans votre sous-répertoire avec des commandes shell.
L'administrateur du système local peut : désactiver l'option lors de la construction de lsof , remplacer le nom de la variable d'environnement LSOFPERSDCPATH par un autre nom, modifier le format HASPERSDC pour inclure le composant du chemin personnel à un autre endroit, ou exclure entièrement le composant de chemin personnel. Consultez la sortie de l'option -D? pour connaître le nom de la variable d'environnement et la spécification du format de HASPERSDC.
Lsof retourne un (1) si des erreurs ont été détectées, ce qui inclut les échecs de localisation de noms de commandes, de noms de fichiers, d'adresses ou de fichiers Internet, de noms de connexion, de fichiers NFS, de PIDs, de PGIDs ou d'UIDs qu'on lui a demandé de lister. Si l'option -V est spécifiée, lsof indiquera les éléments de recherche qu'il n'a pas réussi à lister.
Il renvoie zéro (0) si aucune erreur n'a été détectée et s'il a été capable de lister un tant soit peu d'information sur les arguments de recherche spécifiés.
Quand lsof ne peut accéder à /dev (ou /devices) ou à l'un de ses sous-répertoires, ou obtenir de l'information sur un fichier qui y est présent avec stat(2), il émet un message d'avertissement et continue. Le fait que lsof émette des messages d'avertissement au sujet de fichiers de /dev (ou /devices) inaccessibles est indiqué dans sa sortie d'aide - requise avec les options -h ou -? - avec le message :
Inaccessible /dev warnings are enabled.
(Les avertissements sur l'inaccessibilité de /dev sont autorisés). Le message d'avertissement peut être supprimé avec l'option -w. Il peut également être supprimé par l'administrateur système quand lsof a été compilé en définissant WARNDEVACCESS. Dans ce cas, la sortie des options d'aide inclura le message :
Inaccessible /dev warnings are disabled.
(Les avertissements sur l'inaccessibilité de /dev sont désactivés). Les messages d'avertissement concernant des périphériques inaccessibles disparaissent habituellement après que lsof ait créé un fichier de cache des périphériques en état de fonctionnement.
Pour lister tous les fichiers ouverts, utilisez :
Pour lister tous les fichiers ouverts Internet, x.25 (HP-UX), et de domaine UNIX, utilisez :
Pour lister tous les fichiers réseau IPv4 utilisés par le processus de PID 1234, utilisez :
En supposant que le dialecte UNIX supporte IPv6, pour ne lister que les fichiers réseau IPv6, utilisez :
Pour lister tous les fichiers utilisant un protocole quelconque sur les ports 513, 514 ou 515 de l'hôte wonderland.cc.purdue.edu, utilisez :
Pour lister tous les fichiers utilisant un protocole quelconque sur n'importe quel port de mace.cc.purdue.edu (cc.purdue.edu est le domaine par défaut), utilisez :
Pour lister tous les fichiers ouverts sous le nom de connexion « abe », ou par l'ID utilisateur 1234, ou par le processus 456, 123 ou 789, utilisez :
Pour lister tous les fichiers ouverts sur le périphérique /dev/hd4, utilisez :
Pour trouver le processus qui a ouvert /u/abe/foo, utilisez :
Pour envoyer un SIGHUP au processus qui a ouvert /u/abe/bar, utilisez :
Pour trouver tous les fichiers ouverts, fichiers de socket de domaine UNIX inclus, de nom /dev/log, utilisez :
Pour trouver les processus ayant des fichiers ouverts sur le système de fichiers NFS nommé /nfs/point/montage dont le serveur est inaccessible, et en supposant que votre table de montage fournit le numéro de périphérique pour /nfs/point/montage , utilisez :
Pour effectuer la recherche précédente en supprimant les messages d'avertissement, utilisez :
Pour ignorer le fichier de cache des périphériques, utilisez :
Pour obtenir la sortie des champs de PID et de nom de commande pour chaque processus, le descripteur du fichier, le numéro de périphérique du fichier, et le numéro d'i-noeud du fichier pour chaque fichier de chaque processus, utilisez :
Pour lister les fichiers de descripteurs 1 et 3 de chaque processus exécutant la commande lsof pour l'ID de connexion « abe » toutes les 10 secondes, utilisez :
Pour lister le répertoire de travail courant des processus exécutant une commande qui est longue d'exactement 4 caractères, et qui possède un « o » ou un « O » comme troisième caractère, utilisez cette forme d'expression régulière de l'option -c c :
Pour trouver un fichier socket IPv4 à partir de son adresse numérique en notation pointée associée, utilisez :
Pour trouver un fichier socket IPv6 (quand le dialecte UNIX supporte IPv6) à partir de son adresse numérique en notation double-pointée associée, utilisez :
Pour trouver un fichier socket IPv6 (quand le dialecte UNIX supporte IPv6) à partir d'une adresse numérique en notation double-pointée associée qui comprend beaucoup de zéros - p.ex. l'adresse loop-back - utilisez :
Quand un fichier détient de multiples verrous d'enregistrements, le caractère d'état de verrouillage (qui suit le descripteur de fichier) est dérivé du test de la première structure de verrou, et pas d'une combinaison quelconque des verrous d'enregistrement individuels qui pourraient être décrits par de multiples structures de verrous.
Lsof ne peut rechercher des fichiers ayant des permissions d'accès limitatives par nom à moins qu'il n'ait été installé avec la permission setuid-root. Sinon, il est limité à la recherche de fichiers pour lesquels l'utilisateur ou le groupe set-GID (le cas échéant) a la permission d'accès.
L'affichage de l'adresse de destination d'un socket brut (raw socket) (p.ex. pour ping) dépend du système d'exploitation UNIX. Certains dialectes stockent l'adresse de destination dans le bloc de contrôle du socket brut, d'autres ne le font pas.
Lsof ne peut pas toujours représenter les numéros de périphériques Solaris de la même manière que ls(1). Par exemple, les numéros de périphériques mineur et majeur que rapportent les fonctions lstat(2) et stat(2) pour le répertoire sur lequel les fichiers de CD-ROM sont montés (typiquement /cdrom) ne sont pas les mêmes que ceux qu'il rapporte pour le périphérique sur lequel les fichiers de CD-ROM sont montés (typiquement /dev/sr0). (Lsof rapporte les numéros des répertoires.)
Le support pour les systèmes de fichiers /proc n'est disponible que pour les dialectes BSD, DEC OSF/1, Digital UNIX et Tru64 UNIX, Linux, et les dialectes dérivés de SYSV R4 - p.ex. FreeBSD, NetBSD, OpenBSD, Solaris, UnixWare.
Certains éléments de fichiers de /proc - numéro de périphérique, numéro d'i-noeud, et taille de fichier - sont indisponibles dans certains dialectes. La recherche de fichiers dans un système de fichier /proc peut requérir que le nom du chemin complet soit spécifié.
Aucun descripteur de fichier texte (txt) n'est affiché pour les processus Linux. Toutes les entrées des fichiers situés ailleurs que dans le répertoire de travail courant, le répertoire racine, et les descripteurs de fichiers numériques sont classifiés comme étant des descripteurs mem.
Lsof ne peut rechercher de tubes nommés DEC OSF/1, Digital UNIX et Tru64 UNIX par leur nom, car leur implémentation noyau de lstat(2) renvoie un numéro de périphérique incorrect pour un tube nommé.
Lsof ne peut rapporter complètement ou correctement les verrous sous HP-UX 9.01, 10.20 et 11.00 à cause d'un accès insuffisant aux données de noyau, ou à des erreurs dans les données du noyau. Voyez la FAQ lsof (La section FAQ vous donne son emplacement.) pour les détails.
Le type de fichier AIX SMT est une fabrication. Il est constitué de structures de fichier dont le type (15) n'est pas défini dans le fichier d'en-tête AIX /usr/include/sys/file.h. Une façon de créer de telles structures de fichier est de lancer des clients X avec la variable d'environnement DISPLAY fixée à « :0.0 ».
L'option +|-f[cfgGn] n'est pas supportée sous les systèmes Linux utilisant le mécanisme /proc, car lsof ne lit alors pas les structures noyau depuis la mémoire du noyau.
Ce fichier est également disponible via ftp anonyme sur vic.cc.purdue.edu dans le répertoire pub/tools/unix/lsofFAQ. L'URL est :
Vous pouvez également utiliser cette URL :
Lsof dispose également de miroirs ailleurs. Quand vous accédez à vic.cc.purdue.edu et que vous vous rendez dans le répertoire pub/tools/unix/lsof , vous obtiendrez une liste de quelques sites miroirs. Le répertoire pub/tools/unix/lsof contient également une liste plus complète dans le fichier mirrors. Utilisez les miroirs prudemment - ils n'ont pas tous la dernière révision de lsof.
Certains exécutables lsof précompilés sont disponibles sur vic.cc.purdue.edu, mais leur utilisation est découragée - il vaut mieux que vous construisiez le vôtre à partir des sources. Si vous pensez devoir utiliser un exécutable précompilé, lisez s'il vous plaît les avertissements qui apparaissent dans les fichiers README des sous-répertoires de pub/tools/unix/lsof/binaries et dans les fichiers 00* de la distribution.
On peut trouver plus d'informations sur la distribution de lsof dans son fichier README.lsof_<version>. Si vous avez l'intention d'obtenir la distribution de lsof et de la construire, lisez s.v.p. README.lsof_<version> ainsi que les autres fichiers 00* de la distribution avant d'envoyer des questions à l'auteur.
Les versions 2 et 3 de lsof ont été testées sous des dialectes UNIX plus anciens. Elles sont disponibles via ftp anonyme sur vic.cc.purdue.edu dans le répertoire pub/tools/unix/lsof/OLD.
access(2), awk(1), crash(1), fattach(3C), ff(1), fstat(8), fuser(1), gethostname(2), isprint(3), kill(1), lstat(2), modload(8), mount(8), netstat(1), ofiles(8L), perl(1), ps(1), readlink(2), stat(2), uname(1).