Portabilité des liens des descripteurs de fichiers

Je me suis toujours demandé cela, mais je n'ai jamais pris le temps de le découvrir, alors je vais le faire maintenant - dans quelle mesure l'utilisation illustrée ici de l'un /proc/$$/fd/$Nou de l'autre est-elle portable /dev/fd/$N? Je comprends les garanties POSIX /dev/null, /dev/tty, and /dev/console (même si je ne l'ai découvert que l'autre jour après avoir lu les commentaires sur cette réponse ), mais qu'en est-il de ces autres?

Autant que je sache, ils sont assez courants, mais dans quels systèmes ne puis-je pas m'attendre à les trouver? Pourquoi pas? Est-il plus susceptible d'en trouver un que l'autre? Présenteront-ils toujours des attributs identiques?

J'ai tendance à utiliser ces appareils de manière assez extensive de toutes sortes de façons, et j'aimerais savoir s'il y a une chance que je ne réussisse pas à essayer.

De plus, les questions ci-dessus doivent être comprises comme étant seulement ce que je pense que je voudrais savoir, mais, comme je dois évidemment poser la question en premier lieu, je ne sais peut-être pas mieux à cet égard et elles ne devraient pas être considérées comme des exigences strictes pour une réponse. Indiquez-moi si vous le pouvez, s'il vous plaît.

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/NUMlsof

Unités avec /proc/PID/fd

Linux

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 pstravail - 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/fdstatfstatreadlink

Sous AIX, la procfilescommande affiche des informations sur les fichiers ouverts d'un processus. Sous Solaris, la pfilescommande 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).

Solaris (depuis la version 10 )

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/NUMpfiles

Plan9

/proc/PID/fdest 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.

QNX

/proc/PID/ est un répertoire, mais il ne contient aucune information sur les descripteurs de fichiers.

Unités avec /procmais 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 /procont 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/PIDioctl

• Solaris jusqu'à 2,5
• OSF / 1 maintenant connu sous le nom de Tru64
• IRIX (?)
• SCO (?)

MINIX 3

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

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

Fuser

La fusercommande 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

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:

• AIX

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 lsofla sortie de, assurez-vous d'utiliser le -Fmode (un champ par ligne), de préférence le -F0mode (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' -aoption avec et , par exemple .-p PID-d NUMlsof -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/NUMdup(NUM)/dev/fd

Là où il /dev/fdexiste, 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/fdest un lien symbolique vers /proc/self/fd.
• Sous la plupart des unités ( IRIX , OpenBSD , NetBSD , SCO, Solaris ,…), les entrées dans /dev/fdsont 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/fdrépertoire dynamique qui suit les descripteurs ouverts du processus appelant. Une statique /dev/fdest disponible /dev/fdn'est pas montée.
• Sous OSF / 1 (Tru64), /dev/fdest fourni via fdfs .
• Il n'y en a pas /dev/fdsur AIX ou HP-UX.

La méthode /procest implémentée et les fonctionnalités qu'elle fournit ne sont en aucun cas standardisées, voir par exemple ici . Selon Wikipedia, FreeBSD est en train de "disparaître" /proc, voir ici pour plus de détails .

À partir de /dev, /dev/fd/ne fait pas partie de POSIX ou de la spécification d'utilisateur unique (SUSv3) alors que System V et BSD le prennent en charge.

Addenda:

Linux: /dev/fd/*sont des liens symboliques vers /proc/self/fd.

FreeBSD: /dev/fd/*est fourni via fdescfs.

NetBSD: identique à FreeBSD.

OpenBSD: identique à FreeBSD.

Solaris: a /dev/fd/*.

IRIX: a /dev/fd/*.

Tru64 Unix: /dev/fd/*selon nixdoc.net , la véritable documentation Tru64 de HP est impénétrable (garçon, quel gâchis! Tu ne trouves rien!).

AIX: aucune indication trouvée dans la documentation accessible au public.

HP-UX: identique à AIX.