Przenośność łączy deskryptorów plików

Zawsze zastanawiałem się tego, ale nigdy nie miał czasu, aby dowiedzieć się, więc zrobię to teraz - jak przenośny jest użycie pokazane tutaj którejkolwiek /proc/$$/fd/$Nlub /dev/fd/$N? Rozumiem gwarancje POSIX /dev/null, /dev/tty, and /dev/console (choć dowiedziałem się o tym dopiero następnego dnia po przeczytaniu komentarzy do tej odpowiedzi ), ale co z tymi innymi?

O ile wiem, są dość powszechne, ale w jakich systemach nie mogę się spodziewać ich znalezienia? Dlaczego nie? Czy bardziej prawdopodobne jest znalezienie jednego od drugiego? Czy zawsze będą wykazywać podobne atrybuty?

Zwykle używam tych urządzeń dość szeroko na wszystkie sposoby i chciałbym wiedzieć, czy jest szansa, że ​​nie uda mi się po prostu spróbować.

Powyższe pytania należy rozumieć jedynie jako to, co myślę , że chciałbym wiedzieć, ale ponieważ oczywiście muszę przede wszystkim zadać pytanie, być może nie wiem najlepiej w tym względzie i nie należy ich uważać za surowe Odpowiedź. Proszę mnie wskazać, jeśli możesz.

W dowiązania są quasi-uniwersalny na Linuksie, ale one nie istnieją nigdzie indziej (z wyjątkiem Cygwin które je emuluje). istnieją również w systemach AIX i Solaris, ale nie są dowiązaniami symbolicznymi. Przenośnie, aby uzyskać informacje o otwartych plikach, zainstaluj ./proc/PID/fd/NUM/proc/PID/fd/NUMlsof

Unices z /proc/PID/fd

Linux

Pod Linuksem jest nieco magicznym dowiązaniem symbolicznym do pliku, który proces o identyfikatorze PID otworzył na deskryptorze pliku NUM . Ten link jest magiczny, ponieważ na przykład można go użyć do uzyskania dostępu do pliku, nawet jeśli plik zostanie usunięty. Link będzie również śledził plik poprzez zmiany nazw. to magiczny symboliczny link, który wskazuje, gdzie PID to proces, który uzyskuje dostęp do łącza./proc/PID/fd/NUM/proc/self/proc/PID

Ta funkcja jest obecna na praktycznie wszystkich systemach Linux. Jest dostarczany przez sterownik dla systemu plików proc , który jest technicznie opcjonalny, ale używany do wielu rzeczy (w tym do wykonywania pspracy - czyta z ), że prawie nigdy nie jest pomijany nawet w systemach osadzonych./proc/PID

Cygwin

Cygwin emuluje Linuksa (dla procesów Cygwin) i ./proc/PID/fd/NUM/proc/self

Solaris (od wersji 2.6), AIX

Dla każdego deskryptora pliku istnieją wpisy, ale są one tego samego typu co otwarty plik, więc nie zawierają informacji o ścieżce pliku. Zgłaszają jednak te same informacje, które zgłosiłyby procesowi, w którym plik jest otwarty, więc można ustalić, w którym systemie plików znajduje się plik i jego numer i-węzła. Katalogi pojawiają się jako dowiązania symboliczne, ale są to magiczne dowiązania symboliczne, których można tylko śledzić, i zwraca pusty ciąg./proc/PID/fdstatfstatreadlink

W systemie AIX procfilespolecenie wyświetla niektóre informacje o otwartych plikach procesu. W systemie Solaris pfilespolecenie wyświetla niektóre informacje o otwartych plikach procesu. Nie obejmuje to ścieżki do pliku (w systemie Solaris robi to od wersji Solaris 10, patrz poniżej).

Solaris (od wersji 10 )

Oprócz tego nowoczesne wersje Solaris mają takie, które zawierają dowiązania symboliczne podobne do dowiązań symbolicznych Linuksa . Podaje komunikat informacji o procesie jest otwarte pliki, w tym ścieżek./proc/PID/fd/NUM/proc/PID/path/NUM/proc/PID/fd/NUMpfiles

Plan9

/proc/PID/fdto plik tekstowy, który zawiera jeden rekord (wiersz) na deskryptor pliku otwarty przez proces. Nazwa pliku nie jest tam śledzona.

QNX

/proc/PID/ jest katalogiem, ale nie zawiera żadnych informacji o deskryptorach plików.

Unices /procbez bezpośredniego dostępu do deskryptorów plików

(Uwaga: czasami można uzyskać informacje o otwartych plikach procesu, przeglądając obraz pamięci, który jest dostępny pod /proc. Nie liczę tego jako „bezpośredniego dostępu”).

Unices, gdzie jest plik/proc/PID

Sam system plików proc zaczął się w UNIX 8 edycja, ale z inną strukturą, i przeszedł przez Plan 9 i wrócił do niektórych jednorożców. Myślę, że we wszystkich systemach operacyjnych z /procwpisem dla każdego PID, ale w wielu systemach jest to zwykły plik, a nie katalog. Następujące systemy muszą być czytane za pomocą :/proc/PIDioctl

• Solaris do 2.5
• OSF / 1 znany teraz jako Tru64
• IRIX (?)
• SCO (?)

MINIX 3

MINIX 3 ma serwer procfs, który udostępnia kilka komponentów podobnych do Linuksa, w tym katalogów. Jednak nie ma nie ./proc/PID//proc/PID/fd

FreeBSD

FreeBSD ma katalogi, ale nie zawierają informacji o otwartych deskryptorach plików. (Jest jednak podobny do Linuksa , dający dostęp do pliku wykonywalnego poprzez dowiązanie symboliczne)./proc/PID//proc/PID/file/proc/PID/exe

Procesy FreeBSD są przestarzałe .

Unices bez /proc

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

Informacje o deskryptorze pliku innymi kanałami

Fuser

Do fuserlisty poleceń procesy, które mają określoną otwartego pliku lub plik otwarty na określony punkt montowania. To polecenie jest standardowe (dostępne we wszystkich systemach zgodnych z XSI , tj. POSIX z rozszerzeniem X / Open System Interface).

Za pomocą tego narzędzia nie można przejść od procesu do nazw plików.

Lsof

Lsof oznacza „listę otwartych plików”. Jest to narzędzie innej firmy , dostępne (ale zazwyczaj nie jest częścią domyślnej instalacji) dla większości wariantów Uniksa. Uzyskiwanie informacji o otwartych plikach jest bardzo zależne od systemu, ponieważ powyższa analiza mogła wzbudzić podejrzenia. Konserwator lsof wykonał pracę polegającą na połączeniu tego wszystkiego w jednym interfejsie.

Możesz przeczytać FAQ, aby zobaczyć, z jakimi trudnościami musi się zmierzyć lsof. W większości jednorożców uzyskanie informacji o nazwach otwartych plików wymaga analizy struktur danych jądra. Cytując z FAQ 3.3 „Dlaczego lsof nie zgłasza pełnych nazw ścieżek?”:

Lsof nie może uzyskać komponentów nazwy ścieżki z pamięci podręcznej nazw jądra następujących dialektów:

• AIX

Tylko jądro Linux zapisuje pełne nazwy ścieżek w strukturach, które utrzymuje o otwartych plikach; zamiast tego większość jąder konwertuje nazwy ścieżek na dublety urządzeń i numerów węzłów i wykorzystuje je do późniejszych odwołań do plików po otwarciu plików.

Jeśli chcesz przeanalizować informacje z lsofwyników, pamiętaj o użyciu -Ftrybu (jedno pole na linię), najlepiej -F0trybu (pola rozdzielane zerami). Aby uzyskać informacje o określonym deskryptorze pliku określonego procesu, użyj -aopcji z i np .-p PID-d NUMlsof -a -p 123 -d 0 -F0n

/dev/fd/NUM dla deskryptorów plików bieżącego procesu

Wiele wariantów Uniksa zapewnia procesowi dostęp do otwartych plików za pomocą nazwy pliku: otwarcie jest równoważne wywołaniu . Te nazwy są przydatne, gdy program chce nazwy pliku, ale chcesz przekazać plik już otwarty (np. Potok lub gniazdo); na przykład powłoki, które implementują podstawianie procesów, używają ich tam, gdzie są dostępne (używając tymczasowej nazwanej potoki, gdy jest niedostępna)./dev/fd/NUMdup(NUM)/dev/fd

Tam /dev/fd, gdzie istnieje, zwykle istnieją też (zawsze?) Synonimy (czasem linki symboliczne, czasem twarde linki, czasem magiczne pliki o równoważnych właściwościach) /dev/stdin= /dev/fd/0, /dev/stdout= /dev/fd/1, /dev/stderr= /dev/fd/2.

• Pod Linuksem /dev/fdjest dowiązaniem symbolicznym /proc/self/fd.
• W większości jednorożców ( IRIX , OpenBSD , NetBSD , SCO, Solaris ,…) wpisy w /dev/fdto urządzenia znakowe. Zwykle pojawiają się, czy deskryptor pliku jest otwarty, czy nie, a wpisy dla deskryptorów plików powyżej określonej liczby mogą być niedostępne.
• W systemach FreeBSD i OSX system plików fdescfs zapewnia /dev/fdkatalog dynamiczny zgodny z otwartymi deskryptorami procesu wywołującego. Statyczny /dev/fdjest dostępny /dev/fdnie jest zamontowany.
• Pod OSF / 1 (Tru64) /dev/fdjest dostarczany przez fdfs .
• Nie ma go /dev/fdw systemie AIX ani HP-UX.

Sposób /procjest zaimplementowany, a funkcje, które zapewnia, nie są w żaden sposób ustandaryzowane, patrz na przykład tutaj . Według Wikipedii FreeBSD „wycofuje się” /proc, szczegóły tutaj .

Na dzień /dev, /dev/fd/nie jest częścią POSIX lub Single User Specyfikacja (SUSv3), podczas gdy System V i BSD ją wspierać.

Uzupełnienie:

Linux: /dev/fd/*są dowiązaniami symbolicznymi do /proc/self/fd.

FreeBSD: /dev/fd/*jest dostarczany przez fdescfs.

NetBSD: to samo co FreeBSD.

OpenBSD: to samo co FreeBSD.

Solaris: ma /dev/fd/*.

IRIX: ma /dev/fd/*.

Tru64 Unix: /dev/fd/*według nixdoc.net oryginalna dokumentacja Tru64 w HP jest nieodgadniona (chłopie, co za bałagan! Nic nie znajdziesz!).

AIX: nie znaleziono wskazań w publicznie dostępnej dokumentacji.

HP-UX: taki sam jak AIX.