님아 그 루트를(/) 건들지 마소

함께 일하는 동료가 대량의 파일을 옮기기 위해 mv 를 사용했다.

 

그리고 그 mv 명령어 이후 명령어가 안쳐진다며 얼굴이 상기되었다.

 

[root@rew ~]# ls -al /
-bash: /usr/bin/ls: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory

 

"ls 명령어를 실행하는데 필요한 라이브러리 파일이 없는 것 같아" 라는 메시지다.

 

명령어 친 내용을 찬찬히 보던 중 mv 명령어에 아주 사소하지만 아주 강력한 실수를 포착하게 되었다.

 

상대 경로로써 ./ 가 아닌 절대 경로인 / 를 파일 이동의 대상으로 삼은 것이다. 

 

의도는 다음과 같았으리라 mv ./* /target 그리고 실제로는 mv /* /target 이였다.

 

자 이제 더이상 ls 를 칠 수 없다. 그럼 다른 명령어는 어떨까?

 

라이브러리 문제인가 싶어 ldd 명령어를 사용해 보았으나 동일한 메시지가 발생한다.

 

그래 그럼 mv 로 잘못 옮긴 파일을 다시 원복하자!! 라고 생각했으나 mv 또한 동일한 에러메시지를 보여줬다.

 

[root@rew /]# cd /
[root@rew /]# ls  
-bash: /usr/bin/ls: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory
[root@rew /]# pwd
/

 

cd 와 pwd 는 된다.

 

모든 명령어가 다 안되려면 안되던가 해야하는데 일부 명령어가 사용이 가능하다.

 

조금 딴 소리 한다면 아파트 청약이 되서 모델하우스를 구경하게되면 그곳에서 설명할 때 종종 이런 표현을 사용한다.

 

"이 방의 옷 장농은 빌트인(builtin)이고, 냉장고 또한 빌트인 제품을 구매하실 수 있습니다."

 

빌트인이라고 하면 아파트에 꼭 맞게 설계되어 해당 제품을 사용할 때 우리는 빌트인 이라는 표현을 사용한다.

 

리눅스 운영체제에는 이러한 빌트인 명령어가 존재하는데 그 대표적인 빌트인 명령어가 바로 cd와 pwd 다. 

 

이러한 빌트인 명령어는 운영체제에 꼭 맞게 설계되어 있기에 특별히 명령어(파일)가 실행됨에 있어 추가 라이브러리를 필요로 하지 않는다.

(리눅스의 빌트인 명령어에 대해 궁금하다면 리눅스에서 help 라는 명령어를 사용해보자)

 

어쨌든 ls 는 사실 빌트인 명령어가 아니며 이를 실행하기 위해서는 추가 라이브러리를 필요로 한다.

 

어떤 추가 라이브러리를 사용할까?

 

사실 에러메시지에 힌트가 있었다.

 

/lib64/ld-linux-x86-64.so.2

 

/lib64 디렉토리에 있는 파일이였다.

 

그런데 mv /* /target 을 하면서 /lib64가 /target 으로 옮겨지게 되면서 해당 경로를 못찾는 일이 발생한 문제였다.

 

그런데 경험이 많은 리눅스 형님들은 사실 이조차도 묘하다는 것을 알 수 있을 것이다.

(만약 뭐가 묘한지 모른다면 당신은 형님 반열에 오르지 못한다 미안하다)

 

/lib64 라는 디렉토리는 리눅스에서 심볼릭 링크를 사용해서 사용한다는 점이다.

 

추가로 / 에는 몇 개의 심볼릭 링크가 더 있다는 점이다.

 

그런데 현재로써는 lib64에 대한 심볼릭링크가 사라졌기 때문에 실행이 안되는 문제니 우선 급한대로 lib64에 대한 심볼릭 링크를 살려야 한다.

 

그럼 이제 ln 명령어를 통해 심볼릭 링크를 걸면 이 게임은 끝이다.

 

[root@rew /]# ln -sf /usrlib64 /lib64
-bash: /usr/bin/ln: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory

 

에헤이 조졌네 이거!!!

 

ln 도 빌트인이 아닌 것이다.

 

이대로 모든것을 포기해야하는지 절체절명의 고민에 빠졌다.

 

복구모드에서는 복구가 될까? 이거 클라우드라 한계가 있을텐데? 어떻게 고객 모르게 할 수 있을까? 정말 방법이 없나?

 

그렇게 구글을 찾아해매던 중 유사한 사례에서 사용했다는 한 명령어를 발견하게 된다.

 

그리고 그 명령어에 대한 man 페이지에서 다음의 문구가 확인된다.

sln - create symbolik links 

(https://man7.org/linux/man-pages/man8/sln.8.html)

 

그리고 일단 명령어를 실행해본다.

 

[root@rew /]# sln
Usage: sln src dest|file

For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

 

실행이 된다. 희망이 보인다.

 

/lib는 크게 2개의 링크가 필요하다 과거 32비트 시절의 라이브러리와 64비트의 라이브러리를 모두 해줘야 좋다.

 

[root@rew /]# sln /usr/lib64 /lib64
[root@rew /]# sln /usr/lib /lib
[root@rew /]# ls -al /|grep lib
lrwxrwxrwx    1 root root    8 Jul  5 00:36 lib -> /usr/lib
lrwxrwxrwx    1 root root   10 Jul  5 00:36 lib64 -> /usr/lib64

 

ls 가 된다...이제 한땀 한땀 /target 으로 잘못 넘어간 파일을 다시 원래대로 돌리면서 복구를 수행한다.

 

개 중에는 이미 프로세스로 동작중이였던 애들의 파일들도 있다.

 

이때 mv 를 통해서 해당 프로세스가 정상적으로 동작을 안할 수도 있지만 상황에 따라서는(프로세스가 참조하는 파일이 있냐 

없냐에 따라서 일듯) 정상적으로 프로세스가 동작할 수도 있다.

 

프로세스가 비정상 동작하는 녀석이 있다면 파일 복구를 마치고 반드시 재실행을 하고 정상 동작한다면 반드시는 아니지만 가급적이면 빠른 시일내에 재실행하는 것을 권장한다.

 

/ 는 말이다 사선을 넘는 마법의 문자다

 

님아 제발 그 루트를 건들지 마소