https://www.centos.org/docs/5/html/5.2/Deployment_Guide/s3-proc-self.html 설명하다
이
/proc/self/디렉터리는 현재 실행 중인 프로세스에 대한 링크입니다.
항상 동시에 여러 프로세스가 실행되고 있는데, "현재 실행 중인 프로세스"는 어떤 프로세스인가요?
컨텍스트 전환을 고려하면 "현재 실행 중인 프로세스"는 현재 CPU에서 실행 중인 프로세스와 관련이 있습니까?
"현재 실행 중인 프로세스"는 포그라운드 및 백그라운드 프로세스와 독립적인가요?
답변1
이는 포그라운드 및 백그라운드 프로세스와는 아무런 관련이 없습니다. 현재 실행 중인 프로세스에만 관련됩니다. 커널이 /proc/self"그것이 무엇을 가리키는가?"라는 질문에 대답해야 할 때현재 일정의 PID를 선택하세요.,즉현재 실행 중인 프로세스(현재 논리 CPU에서)입니다. 그 효과는 /proc/self실행하는 경우 항상 요청하는 프로그램의 pid를 가리키는 것입니다.
ls -l /proc/self
pid가 표시 ls되고 해당 코드를 사용하는 코드를 작성하면 /proc/self자체 pid 등이 표시됩니다.
답변2
기호 링크에 액세스합니다(readlink()를 호출하거나 이를 통과하는 경로에서 open()을 호출). 당시에는 CPU에서 실행되지만 관련이 없습니다. 다중 프로세서 시스템은 CPU에서 여러 프로세스를 동시에 실행할 수 있습니다.
포그라운드 및 백그라운드 프로세스는 기본적으로 셸 구성이며 시스템의 모든 셸 세션에 대해 하나가 있으므로 고유한 포그라운드 프로세스가 없습니다.
답변3
문구가 더 좋았을 수도 있지만, 자기 참조적 아이디어를 표현하기 위해 작성하려는 문구는 혼란스러울 것입니다. 디렉토리 이름이 더 설명적이라고 생각합니다.
기본적으로 는 /proc/self/읽는 과정을 나타냅니다 /proc/self/. 따라서 /proc/self/C 프로그램에서 열려고 하면 해당 프로그램을 나타냅니다. 쉘에서 이 작업을 수행하려는 경우 쉘 등입니다.
하지만 멀티태스킹 대신 실제로 4개의 프로세스를 동시에 실행할 수 있는 쿼드 코어 CPU가 있다면 어떨까요?
그러면 각 프로세스는 /proc/self/서로의 현실을 볼 수 없어도 다른 버전의 현실을 보게 됩니다 /proc/self/.
어떻게 작동하나요?
글쎄, /proc/self/실제로는 폴더가 아닙니다. 장치 드라이버이며, 접근하려고 하면 폴더 형태로 노출됩니다. 폴더에 필요한 API를 구현하기 때문입니다. 디렉토리 /proc/self/만이 이 작업을 수행하는 것은 아닙니다. 원격 서버에서 공유 폴더를 마운트하거나 USB 썸 드라이브 또는 드롭박스를 마운트하는 것을 고려해보세요. 이들은 모두 동일한 API 세트를 구현하여 작동하며 폴더처럼 작동합니다.
프로세스가 장치 드라이버에 액세스하려고 하면 /proc/self/장치 드라이버는 프로세스에서 데이터를 읽어 해당 내용을 동적으로 생성합니다. 따라서 내부 파일은 /proc/self/실제로 존재하지 않습니다. 그것은 그것을 관찰하려는 과정을 다시 반사하는 거울과 같습니다.
정말 장치 드라이버인가요? 너무 단순화하신 것 같네요!
네 확실합니다. 현명해지고 싶다면 커널 모듈이 있습니다. 그러나 다양한 Linux 개발자 채널의 유즈넷 게시물을 보면 대부분의 커널 개발자는 "장치 드라이버"와 "커널 모듈"을 같은 의미로 사용합니다. 저는 Linux용 장치 드라이버, 즉 커널 모듈을 작성하곤 했습니다. Linux에서 자신만의 인터페이스를 작성하려는 경우 /proc/, 예를 들어 이 웹 사이트의 게시물을 반환하는 파일 시스템을 원하는 경우 /proc/unix.stackexchange/O'Reilly에서 출판한 유명한 "Linux Device Drivers" 책에서 이를 수행하는 방법을 배울 수 있습니다. 온라인에서도 소프트카피로 볼 수 있습니다.
답변4
/proc/self는 구문 설탕입니다. 이는 /proc/를 getpid() 시스템 호출의 결과(bash에서 메타변수 $$로 액세스 가능)와 연결하는 지름길입니다. 그러나 쉘 스크립팅의 경우 많은 명령문이 자체 PID를 사용하여 다른 프로세스를 호출하기 때문에 혼란스러울 수 있습니다. PID는 일반적으로 죽은 프로세스를 참조합니다. 고려하다:
root@vps01:~# ls -l /proc/self/fd
total 0
lrwx------ 1 root root 64 Jan 1 01:51 0 -> /dev/pts/0
lrwx------ 1 root root 64 Jan 1 01:51 1 -> /dev/pts/0
lrwx------ 1 root root 64 Jan 1 01:51 2 -> /dev/pts/0
lr-x------ 1 root root 64 Jan 1 01:51 3 -> /proc/26562/fd
root@vps01:~# echo $$
593
'/bin/ls'는 디렉토리 경로를 평가하여 /proc/26563으로 해석합니다. 이는 디렉토리 내용을 읽는 프로세스(새로 생성된 /bin/ls 프로세스)의 PID이기 때문입니다. 그러나 파이프라인의 다음 프로세스(셸 스크립트인 경우) 또는 프롬프트가 반환되면(대화형 셸인 경우)경로가 더 이상 존재하지 않습니다.정보 출력은 존재하지 않는 프로세스를 의미합니다.
그러나 이는 외부 명령(쉘 자체에 내장되지 않은 실제 실행 프로그램 파일)에만 작동합니다. 따라서 경로 이름을 외부 프로세스 /bin/ls에 전달하는 대신 파일 이름 globbing을 사용하여 디렉터리 내용 목록을 가져오는 경우 다른 결과를 얻게 됩니다.
root@vps01:~# ls /proc/self/fd
0 1 2 3
root@vps01:~/specs# echo /proc/self/fd/*
/proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/2 /proc/self/fd/255 /proc/self/fd/3
첫 번째 줄에서 쉘은 exec() 시스템 호출을 통해 새 프로세스 "/bin/ls"를 생성하고 "/proc/self/fd"를 argv[1]로 전달합니다. '/bin/ls'는 /proc/self/fd 디렉터리를 차례로 열고 반복하는 동안 해당 내용을 읽고 인쇄합니다.
그러나 두 번째 줄에서는 뒤에서 glob()을 사용하여 파일 이름 목록을 확장하고 에코를 위해 문자열 배열로 전달합니다. (보통 내부 명령으로 구현되지만 일반적으로 /bin/echo 바이너리도 있습니다... 하지만 echo는 문자열만 처리하므로 해당 부분은 실제로 중요하지 않으며 경로 이름과 관련된 시스템 호출에는 절대 제공되지 않습니다.)
이제 다음 상황을 고려해보세요.
root@vps01:~# cd /proc/self/fd
root@vps01:~# ls
0 1 2 255
여기 껍질,상위 프로세스/bin/ls, /proc/self가 하위 디렉터리로 만들어졌습니다.현재 디렉터리. 따라서 상대 경로 이름은 해당 관점에서 평가됩니다. 내 추측으로는 이것이 파일에 대한 여러 하드 링크를 생성할 수 있는 POSIX 파일 의미론과 관련이 있다는 것입니다.포함하다열려 있는 파일 설명자. 따라서 이번에는 /bin/ls가 echo /proc/$$/fd/*처럼 동작합니다.