https://www.centos.org/docs/5/html/5.2/Deployment_Guide/s3-proc-self.html 말한다
/proc/self/디렉토리는 현재 실행중인 프로세스에 대한 링크입니다.
항상 동시에 여러 프로세스가 실행 중이므로 어떤 프로세스가 "현재 실행중인 프로세스"입니까?
"현재 실행중인 프로세스"는 컨텍스트 전환을 고려하여 CPU에서 현재 실행중인 프로세스와 관련이 있습니까?
"현재 실행중인 프로세스"는 포 그라운드 및 백그라운드 프로세스와 관련이 없습니까?
답변:
포 그라운드 및 백그라운드 프로세스와는 아무런 관련이 없습니다. 현재 실행중인 프로세스와 만 관련이 있습니다. 커널이“무엇을 /proc/self가리키고 있습니까?”라는 질문에 대답해야 할 때, 현재 예약 된 pid , 즉 현재 실행중인 프로세스 (현재 논리 CPU에서)를 선택합니다. 결과는 /proc/self항상 묻는 프로그램의 pid를 가리 킵니다. 당신이 실행하는 경우
ls -l /proc/self
당신은 lspid 를 보게 될 것이다 . 만약 당신이 /proc/self그 코드 를 사용 하는 코드 를 작성한다면 그 자신의 pid를 볼 것이다
/proc/self인수 중 하나의 경로 이름의 일부로 사용할 수 있습니다.
표현은 더 나을 수 있지만 다시 한 번 자기 참조의 아이디어를 표현하기 위해 작성하려는 표현은 혼란 스러울 것입니다. 디렉토리의 이름은 내 의견으로는 더 설명 적입니다.
기본적으로 /proc/self/읽는 프로세스를 나타냅니다 /proc/self/. 따라서 /proc/self/C 프로그램에서 열려고하면 해당 프로그램을 나타냅니다. 쉘에서 시도하면 쉘 등입니다.
그러나 실제로 멀티 태스킹이 아닌 4 개의 프로세스를 동시에 실행할 수있는 쿼드 코어 CPU가 있다면 어떨까요?
그러면 각 프로세스는 서로 /proc/self/를 보지 않고도 실제와 는 다르게 보일 것 /proc/self/입니다.
어떻게 작동합니까?
글쎄, /proc/self/실제로 폴더가 아닙니다. 액세스하려고하면 폴더로 자신을 노출시키는 장치 드라이버입니다. 폴더에 필요한 API를 구현하기 때문입니다. /proc/self/디렉토리에서이 작업을 수행하는 유일한 것이 아니다. 원격 서버 또는 USB 썸 드라이브 또는 보관 용 컴퓨터에 마운트 된 공유 폴더를 고려하십시오. 이들은 모두 폴더처럼 동작하도록하는 동일한 API 세트를 구현하여 작동합니다.
프로세스가 액세스를 시도 /proc/self/하면 장치 드라이버는 해당 프로세스에서 데이터를 읽어 내용을 동적으로 생성합니다. 따라서 파일 /proc/self/이 실제로 존재하지 않습니다. 거울을 보는 과정을 다시 반영하는 거울과 같습니다.
정말 장치 드라이버입니까? 지나치게 단순화하는 것처럼 들립니다!
그렇습니다. 당신이 pedantic하고 싶다면 그것은 커널 모듈입니다. 그러나 다양한 Linux 개발자 채널에서 유즈넷 게시를 확인하면 대부분의 커널 개발자는 "장치 드라이버"와 "커널 모듈"을 서로 바꿔 사용할 수 있습니다. 나는 리눅스를위한 장치 드라이버, 커널 모듈을 작성했었다. 당신이 당신의 자신의 인터페이스를 작성하려는 경우 /proc/, 예를 들어 말을 당신이 원하는 /proc/unix.stackexchange/이 웹 사이트에서 반환 게시물은 오라일리에서 발표 한 유서 깊은 "리눅스 디바이스 드라이버"책에서 작업을 수행하는 방법에 대한 읽을 수있는 파일 시스템. 온라인으로 소프트 카피로 이용할 수도 있습니다.
/proc/self장치 드라이버는 아니지만 대신 커널 노출 파일 시스템의 일부입니다 procfs.
/proc되어 있습니다. 훌륭한 책 "Linux 장치 드라이버" 에는 기본 드라이버의 구현 예제도 있습니다. 나는 대학에서 하나를 구현해야한다는 것을 알아야합니다. 아마도 "커널 모듈"이라는 용어를 대신 사용했을 수도 있지만 "장치 드라이버"는 대부분의 사람들에게 익숙하며 "커널 모듈"과 "장치 드라이버"사이에 큰 차이가 있다는 잘못된 인상을주고 싶지 않습니다. 용어 외에.
액세스중인 프로세스 /proc/self나 파일 / 폴더 에있는 프로세스 입니다.
시도하십시오 cat /proc/self/cmdline. 당신은 깜짝 놀랄 얻을 것이다 cat /proc/self/cmdline(실제로, 대신 공간의 사이에 널 (null) 문자가있을 것 t하고 /는이 가상 파일 (pseudofile)에 액세스하는 고양이 과정이 될 것이기 때문에).
를 수행 ls -l /proc/self하면 ls 프로세스 자체의 pid가 표시됩니다. 아니면 어떻습니까 ls -l /proc/self/exe; ls 실행 파일을 가리 킵니다.
또는 변경을 위해 이것을 시도하십시오.
$ cp /proc/self/cmdline /tmp/cmd
$ hexdump -C /tmp/cmd
00000000 63 70 00 2f 70 72 6f 63 2f 73 65 6c 66 2f 63 6d |cp./proc/self/cm|
00000010 64 6c 69 6e 65 00 2f 74 6d 70 2f 63 6d 64 00 |dline./tmp/cmd.|
0000001f
또는
$ hexdump -C /proc/self/cmdline
00000000 68 65 78 64 75 6d 70 00 2d 43 00 2f 70 72 6f 63 |hexdump.-C./proc|
00000010 2f 73 65 6c 66 2f 63 6d 64 6c 69 6e 65 00 |/self/cmdline.|
0000001e
내가 말했듯이, 프로세스 /proc/self또는 파일 / 폴더에 액세스하는 프로세스가 있습니다 .
/ proc / self는 구문 설탕입니다. / proc /를 오염시키는 지름길이며 getpid () syscall의 결과입니다 (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'는 디렉토리의 경로를 평가하여 디렉토리의 내용을 읽는 프로세스의 PID (새로 작성된 / bin / ls 프로세스)이므로 / proc / 26563으로 해석합니다. 그러나 파이프 라인의 다음 프로세스, 셸 스크립팅의 경우 또는 프롬프트가 표시 될 때까지 (대화식 셸의 경우) 경로가 더 이상 존재하지 않고 정보 출력이 존재하지 않는 프로세스를 나타냅니다.
그러나 이것은 외부 명령에만 적용됩니다 (쉘 자체에 내장되는 것이 아니라 실제 실행 가능한 프로그램 파일 인 명령). 따라서 경로 이름을 외부 프로세스 / bin / ls에 전달하지 않고 filename 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 () syscall을 통해 '/ bin / ls'라는 새로운 프로세스를 생성하고 "/ proc / self / fd"를 argv [1]로 전달했습니다. '/ bin / ls'는 차례로 / proc / self / fd 디렉토리를 열고 그 내용을 반복해서 읽은 다음 인쇄합니다.
그러나 두 번째 줄은 장면 뒤에 glob ()를 사용하여 파일 이름 목록을 확장합니다. 이것들은 반향 할 문자열 배열로 전달됩니다. (일반적으로 내부 명령으로 구현되지만 종종 / bin / echo 바이너리도 있습니다.하지만 에코는 문자열 만 다루기 때문에 해당 부분은 실제로 관련이 없습니다. 경로 이름과 관련된 모든 syscall에는 절대로 공급되지 않습니다.)
이제 다음 사례를 고려하십시오.
root@vps01:~# cd /proc/self/fd
root@vps01:~# ls
0 1 2 255
여기서 / bin / ls 의 상위 프로세스 인 쉘 은 / proc / self의 하위 디렉토리를 현재 디렉토리 로 만들었습니다 . 따라서 상대 경로 이름은 관점에서 평가됩니다. 가장 좋은 추측은 POSIX 파일 의미와 관련이 있으며 열려있는 파일 설명자를 포함하여 파일에 대한 여러 하드 링크를 만들 수 있습니다 . 따라서 이번에는 / bin / ls가 / proc / $$ / fd / *와 비슷하게 동작합니다.
쉘이 별도의 프로세스에서 ls와 같은 프로그램을 호출함에 따라 / proc / self는 nnnnn에 대한 심볼릭 링크 로 표시됩니다 . 여기서 nnnnn 은 ls 프로세스의 프로세스 ID입니다. 내가 아는 한, 일반적으로 사용되는 쉘에는 심볼릭 링크를 읽을 수있는 내장 기능이 없지만 Perl에는 다음이 있습니다.
perl -e 'print "/ proc / self link :", readlink ( "/ proc / self"), "-pid $$ \ n";'
따라서 / proc / self는 심볼릭 링크처럼 동작하지만 procfs 파일 시스템은이를 "매직"프로세스 인식으로 만듭니다.
/proc/self물론 평가 하는 과정.