Portabilità dei collegamenti ai descrittori di file

Mi sono sempre chiesto questo, ma non ho mai avuto il tempo di scoprirlo, quindi lo farò ora - quanto è portatile l'utilizzo mostrato qui di uno /proc/$$/fd/$No entrambi /dev/fd/$N? Comprendo le garanzie POSIX /dev/null, /dev/tty, and /dev/console (anche se l'ho scoperto solo l'altro giorno dopo aver letto i commenti su questa risposta ) ma che dire di questi altri?

Per quanto ne so, sono piuttosto comuni, ma in quali sistemi non posso aspettarmi di trovarli? Perchè no? È più probabile trovarne uno rispetto all'altro? Esibiranno sempre come attributi?

Tendo a usare questi dispositivi abbastanza ampiamente in tutti i modi e mi piacerebbe sapere se c'è una possibilità di venire a corto di tentativi.

Anche le domande di cui sopra dovrebbero essere intese come solo ciò che penso che mi piacerebbe sapere, ma, dal momento che ovviamente devo chiederlo in primo luogo, potrei non sapere meglio a questo proposito e non dovrebbero essere considerati requisiti rigorosi per una domanda. Fammi sapere se puoi, per favore.

I collegamenti simbolici sono quasi universali su Linux, ma non esistono altrove (tranne su Cygwin che li emula). esistono anche su AIX e Solaris, ma non sono collegamenti simbolici. Portabilmente, per ottenere informazioni sui file aperti, installa ./proc/PID/fd/NUM/proc/PID/fd/NUMlsof

Unices with /proc/PID/fd

Linux

Sotto Linux, c'è un collegamento simbolico leggermente magico al file che il processo con ID PID ha aperto sul descrittore di file NUM . Questo collegamento è magico in quanto, ad esempio, può essere utilizzato per accedere al file anche se il file viene rimosso. Il collegamento seguirà anche il file attraverso i nomi. è un collegamento simbolico magico che indica dove PID è il processo che accede al collegamento./proc/PID/fd/NUM/proc/self/proc/PID

Questa funzione è presente praticamente su tutti i sistemi Linux. È fornito dal driver per il filesystem proc , che è tecnicamente opzionale ma usato per così tante cose (incluso fare il pslavoro - legge da ) che non viene quasi mai escluso nemmeno su sistemi embedded./proc/PID

Cygwin

Cygwin emula Linux (per i processi Cygwin) e ./proc/PID/fd/NUM/proc/self

Solaris (dalla versione 2.6), AIX

Esistono voci per ciascun descrittore di file, ma appaiono dello stesso tipo del file aperto, quindi non forniscono informazioni sul percorso del file. Tuttavia, riportano le stesse informazioni che riferirebbero al processo che ha il file aperto, quindi è possibile determinare su quale filesystem si trova il file e il suo numero di inode. Le directory appaiono come collegamenti simbolici, tuttavia sono collegamenti simbolici magici che possono essere solo seguiti e restituiscono una stringa vuota./proc/PID/fdstatfstatreadlink

In AIX, il procfilescomando visualizza alcune informazioni sui file aperti di un processo. In Solaris, il pfilescomando visualizza alcune informazioni sui file aperti di un processo. Questo non include il percorso del file (su Solaris, lo fa da Solaris 10, vedere di seguito).

Solaris (dalla versione 10 )

Inoltre , nelle moderne versioni di Solaris sono presenti collegamenti simbolici simili ai collegamenti simbolici di Linux in . Il comando mostra informazioni sui file aperti di un processo, inclusi i percorsi./proc/PID/fd/NUM/proc/PID/path/NUM/proc/PID/fd/NUMpfiles

Plan9

/proc/PID/fdè un file di testo che contiene un record (riga) per descrittore di file aperto dal processo. Il nome del file non viene tracciato lì.

QNX

/proc/PID/ è una directory, ma non contiene alcuna informazione sui descrittori di file.

Unices /procsenza accesso diretto ai descrittori di file

(Nota: a volte è possibile ottenere informazioni sui file aperti di un processo sfogliando la sua immagine di memoria che è accessibile sotto /proc. Non lo considero come "accesso diretto".)

Unices dove si trova un file/proc/PID

Lo stesso filesystem proc è iniziato con l' UNIX ottava edizione, ma con una struttura diversa, ed è passato attraverso il Piano 9 e poi è tornato ad alcuni Unix. Penso che tutti i sistemi operativi con un /prochanno una voce per ogni PID, ma su molti sistemi, è un file normale, non una directory. I seguenti sistemi hanno un che deve essere letto con :/proc/PIDioctl

• Solaris fino a 2,5
• OSF / 1 ora noto come Tru64
• IRIX (?)
• SCO (?)

MINIX 3

MINIX 3 ha un server procfs che fornisce diversi componenti simili a Linux, incluse le directory. Tuttavia, questo non esiste ./proc/PID//proc/PID/fd

FreeBSD

FreeBSD ha delle directory, ma non forniscono informazioni sui descrittori di file aperti. (Esiste tuttavia un metodo simile a quello di Linux , che consente l'accesso all'eseguibile tramite un collegamento simbolico.)/proc/PID//proc/PID/file/proc/PID/exe

I procfs di FreeBSD sono deprecati .

Unices senza /proc

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

Informazioni sul descrittore di file tramite altri canali

fuser

Il fusercomando elenca i processi che hanno un file specificato aperto o un file aperto sul punto di montaggio specificato. Questo comando è standard (disponibile su tutti i sistemi conformi a XSI , ovvero POSIX con l'estensione dell'interfaccia di sistema X / Open).

Non è possibile passare da un processo a nomi di file con questa utility.

lsof

Lsof significa "elenco file aperti". È uno strumento di terze parti , disponibile (ma di solito non fa parte dell'installazione predefinita) per la maggior parte delle varianti di unix. Ottenere informazioni sui file aperti dipende molto dal sistema, poiché l'analisi sopra potrebbe averti fatto sospettare. Il manutentore lsof ha fatto il lavoro di combinare tutto sotto un'unica interfaccia.

Puoi leggere le FAQ per vedere quali tipi di difficoltà lsof deve affrontare. Sulla maggior parte degli unices, ottenere informazioni sui nomi dei file aperti richiede l'analisi delle strutture di dati del kernel. Citando dalla domanda frequente 3.3 "Perché lsof non riporta i nomi dei percorsi completi?":

Lsof non è in grado di ottenere componenti del nome percorso dalle cache dei nomi kernel dei seguenti dialetti:

• AIX

Solo il kernel Linux registra i nomi dei percorsi completi nelle strutture che gestisce sui file aperti; invece, la maggior parte dei kernel converte i nomi dei percorsi in doppiette di dispositivi e numeri di nodo e li usa per riferimenti di file successivi dopo l'apertura dei file.

Se è necessario analizzare le informazioni lsofdall'output, assicurarsi di utilizzare la -Fmodalità (un campo per riga), preferibilmente la -F0modalità (campi delimitati da null). Per ottenere informazioni su un descrittore di file specifico di un processo specifico, utilizzare l' -aopzione con e , ad es .-p PID-d NUMlsof -a -p 123 -d 0 -F0n

/dev/fd/NUM per i descrittori di file del processo corrente

Molte varianti unix consentono a un processo di accedere ai suoi file aperti tramite un nome file: l'apertura è equivalente alla chiamata . Questi nomi sono utili quando un programma desidera un nome di file ma si desidera passare un file già aperto (ad esempio una pipe o un socket); ad esempio le shell che implementano la sostituzione di processo le usano dove disponibili (usando una pipe denominata temporanea dove non è disponibile)./dev/fd/NUMdup(NUM)/dev/fd

Dove /dev/fdesiste, di solito ci sono anche (sempre?) Sinonimi (a volte collegamenti simbolici, a volte collegamenti rigidi, a volte file magici con proprietà equivalenti) /dev/stdin= /dev/fd/0, /dev/stdout= /dev/fd/1, /dev/stderr= /dev/fd/2.

• Sotto Linux, /dev/fdc'è un collegamento simbolico a /proc/self/fd.
• Nella maggior parte dei computer ( IRIX , OpenBSD , NetBSD , SCO, Solaris , ...), le voci in /dev/fdsono dispositivi a caratteri. Di solito vengono visualizzati se il descrittore di file è aperto o meno e le voci potrebbero non essere disponibili per i descrittori di file superiori a un determinato numero.
• Sotto FreeBSD e OSX, il filesystem fdescfs fornisce una /dev/fddirectory dinamica che segue i descrittori aperti del processo di chiamata. Uno statico /dev/fdè disponibile /dev/fdnon è montato.
• In OSF / 1 (Tru64), /dev/fdviene fornito tramite fdfs .
• Non è disponibile /dev/fdsu AIX o HP-UX.

Il modo in cui /procviene implementato e le funzionalità fornite non sono standardizzate in alcun modo, vedere ad esempio qui . Secondo Wikipedia, FreeBSD si sta "ritirando gradualmente" /proc, vedi qui per i dettagli .

A partire da /dev, /dev/fd/non fa parte di POSIX o Single User Specification (SUSv3) mentre System V e BSD lo supportano.

Addendum:

Linux: /dev/fd/*sono collegamenti simbolici a /proc/self/fd.

FreeBSD: /dev/fd/*è fornito tramite fdescfs.

NetBSD: uguale a FreeBSD.

OpenBSD: uguale a FreeBSD.

Solaris: ha /dev/fd/*.

IRIX: ha /dev/fd/*.

Tru64 Unix: /dev/fd/*secondo nixdoc.net , la documentazione Tru64 originale su HP è imperscrutabile (ragazzo, che casino! Non trovi nulla!).

AIX: nessuna indicazione trovata nella documentazione disponibile al pubblico.

HP-UX: uguale ad AIX.