[linux] bin, sbin, 심볼릭 링크(Symbolic Link),하드 링크

리눅스는 내가 실행하려는 프로세스의 이름을 어떻게 인식하는 것일까?
javac -version 을 물어보면 알려주고, nginx -version 을 물어보면 알려준다.
그런데 tomcat은 command not found를 내뱉는다. 

왜 tomcat -version은 되지 않을까? 차별당하는 톰캣.

다음은 리눅스에서 실행파일(binary파일)을 관리하는 6개의 디렉토리이다.
이 6개의 디렉토리를 바이너리디렉토리라고 칭해본다.
bin: 일반 실행파일
sbin: 시스템 관련 실행파일

/bin : 커널에서 이용하는 리눅스의 기본 명령어가 들어 있다.
/sbin : 커널에서 이용하는 시스템 관련 명령어가 들어 있다.
/usr/bin : 사용자 환경에서 사용하는 명령어가 들어 있다.
/usr/sbin : 사용자 환경에서 사용하는 시스템 관련 명령어가 들어 있다.
/usr/local/bin : 사용자가 설치한 bin관련 파일이 담긴다.
/usr/local/sbin : 사용자가 설치한 sbin관련 파일이 담긴다.

ㄴ.명령어든 파일이든 리눅스가 실행시키는 것들은 bin 또는 sbin에 담겨있다고 이해해보았다.

해당 디렉토리에서 java를 찾아보았다.
/bin 디렉토리와 /usr/bin 디렉토리에 자바 관련 파일들이 셋팅되어 있다.

bin디렉토리 속에 java들이 있다. which java가 가리키는 경로는 jvm 디렉토리 하위 경로다.

which java로 java의 위치를 확인해보니 /bin이나 /usr/bin이 아니라  jdk설치 디렉토리의 경로가 나온다.
/bin 과 /usr/bin에 실행 파일이 있지만 실제로  "java"라는 키워드로 리눅스가 참조하는 곳은 다른 곳이다.

java 심볼릭 링크가 가리키는 경로와 같다.

java의 심볼릭 링크(바로가기) 셋팅이 되어 있다. which java로 출력되는 경로와 일치한다.

심볼릭 링크는 바로가기를 만드는 것이다.
java라는 키워드가 실제로는 어떤 파일을 가리킬 것인지 설정할 수 있다.
ln -s java <자바경로>
<자바 경로>를 바꿔주면서 심볼릭링크가 가리키는 원본 파일을 변경할 수 있다.
리눅스가 인식하는 java의 버전을 바꿔가면서 여러 버전을 사용할 수 있는 것이다.

nginx의 경우 /usr/sbin 경로에 위치한 nginx 경로를 출력한다.

which nginx가 가리키는 경로는 /usr/sbin/nginx이다.

 

nginx가 만들어낸 아름다운 그림

 

결론
1. 리눅스는 binary 관련 6개의 디렉토리에서 실행할 수 있는 파일을 찾는다.
2. 심볼릭 링크(바로가기)가 되어 있는 경우  심볼릭 링크를 우선으로 참조한다.
3. tomcat은 바이너리디렉토리에도 심볼릭 링크에도 없기 때문에 찾지 못한다.
4.리눅스가 실행시키는 명령어든 파일이든 모두 바이너리디렉토리 하위에 존재한다.

 

하드 링크
같은 이름이 파일을 하나 더 만든다.
원본 파일과 하드 링크 파일의 inode 값이 같다.
하드 링크로 만들어진 파일의 용량은 같지만 실제로 늘어난 용량은 없음 (용량도 늘어나는 cp 명령어와의 차이점)
하드 링크 파일을 지워도 원본 파일에 상관없이 내용을 찾아갈 수 있다.

심볼릭 링크
원본 파일을 가리키는 파일을 만든다.
원본 파일이 사라지면 심볼릭 링크 파일의 역할을 할 수 없다.
하지만 원본 파일을 같은 이름으로 생성해준다면 다시 역할을 하게 된다.
주로 복잡한 경로의 디렉토리를 쉽게 접근할 때 사용하고 확장자를 하나로 통일할 때 사용할 수 있다.

아이노드(i-node)
각각의 파일에 대한 메타정보를 기억하는 120바이트 고정크기의 구조체.
아이노드는 식별 번호를 가진다.
하드링크는 다른 파일인데 같은 아이노드를 가진다. 변경사항은 
자동으로 서로에게 반영된다. 동기화된다.
원본파일과 동기화되는 복사체

소프트링크(심볼릭링크) 는 원본과 링크파일의 inode번호가 다르다.
원본 파일을 가리키는 바로가기 파일.
원본이 삭제되면 사라짐.
링크파일에 대한 작업은 실제로 가리키는 원본파일에서 작업됨.