메뉴 건너뛰기

검색창 닫기

GREATUSER

tech

Control-D 화면에 대한 고찰

위대한유저 2009.03.13 00:34 조회 수 : 43835


 

1 Control-D 화면이란 무엇인가? #

음.. 저는 이것이 정식 명칭인지 모릅니다..
하지만 제가 회사내에서 업무를 하던도중 같은 상황을 만나면.. 이렇게 부릅니다..
물론 저말고도 다른 직원들은 이렇게 부르는 경우가 많습니다.. 아님 말구.. -_-;;;;
그럼 이게 뭐냐?
(Contro-D):
프롬프트가 나오는 화면입니다. ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
-_-;

리눅스를 부팅하는 과정에서 운이 좋으면(?) 볼 수 있는 화면인데...
화면의 안내중 Control-D 라는 문구가 오늘 설명하려는 문제의 상황에서 나타날 수 있기 때문입니다...
이후 원활한 진행을 위해서 간단하게 언급하자면..

화면의 안내에 따라서 2가지를 선택할 수 있습니다.
  • Control+D 입력 : 시스템이 바로 리부팅됨
  • 루트패스워드 입력 : 시스템에 로긴되어 프롬프트가 떨어짐 (단 정상적인 운영상태는 아님)
     


    •  

    2 문제의 확인

    위에서도 설명한것처럼 "Control-D" 화면은 부팅시에 나타나게 되는데..
    나타나는 원인이 몇가지 있습니다..

    관리자의 실수 또는 저장장치관련 이상이 발생했을 경우입니다...
    흠 너무 당연하면서 모호 한가요? --;;;;;;
    어차피 그런 생각이 들었다면 그대에게는 숨쉬는것도 운동입니다.
    앞으로의 내용을 차근차근 읽어보도록 합시다...


     

    2.1 fstab의 오류

    바로 관리자의 실수에대한 대표적 사례이자 유일할 수 있는 사례 입니다..
    지난 시간에 fstab의 수정에대한 내용을 학습한바 있습니다.
    강좌 마지막 부분에 fstab 파일을 잘못 수정했을 경우 시스템이 정상부팅 되지 않는다고 했었죠?
    (만약 이 내용을 모르신다면 이전 내용을 참고하시기 바랍니다... )
    그렇습니다. 바로 그 상황(fstab의 오류)에서 "Control-D"화면이 나오면서 진행이 안되는 것입니다..
    이런경우 부팅 완료가 되지 않기 때문에 로컬에서 직접 작업을 할 수 밖에 없게되지요..

    근데... 그럼 fstab 을 잘못수정하면 이 화면이 나오는것인가? 라고 물을 수 있겠지만..
    fstab의 수정오류는 발생시킬 수 있는 원인중 하나일뿐.. 오류수정 때문에 Control-D 화면이 나오는것은 아닙니다.
    보다 정확히 설명하자면..
    /etc/fstab 파일에 등록한 디바이스를 마운트 시킬때 어떤 이유에선지 정상적으로 디바이스를
    마운트하지 못하는 상황에서 나타난다고 이해를 하면 될것 같습니다.


    만약에 이런 상황에 봉착해서 "Control-D"화면을 만났을때 그럼 어떻게 하느냐???
    최종적인 해결여부를 떠나서 가장처음 어떻게 진행해야 할까요?
    요거 위에서 언급 했었죠?
    • 첫번째 : Control-D 가 눈에 띄니까 그대로 실행한다.
       
    • 두번째 : 루트패스워드를 입력하고 로그인한다.
       

      • 당연히 패스워드를 입력하고 로그인을 해야합니다.
      무심코 Control-D 를 입력할 수도 있습니다... 그럼 리부팅이 되겠지요...
      그런데 그다음에도 또 똑같이 Control-D를 입력한다면....
      후... 알지? 넌 이일과 전혀 맞지 않는다는걸....

      제가 이것을 로그인 하라고 지시하는것은..
      처음에 이런 문제에 봉착한 순간에... "아~ fstab의 설정오류구나.. " 라고 판단하는 것이 쉽지 않기 때문입니다.
      물론 자신이 설정파일을 수정하고 리부팅 했을경우
      "내가 실행한것은 현재 봉착한 상황과 관련된 것이며, 영향을 미칠만 하겠구나"
      라는 센스를 가지고 있는 분이라면 얘기가 다르지만..
      아무튼 본 메뉴얼은 어떤 상황인지 알 수 없는 일반인의 경우를 기준으로 설명합니다...

      자 이제 로그인을 하셨다면... 진짜 fstab의 설정이 틀렸는지를 봅시다...
      어떻게 한다고 했죠?
      네..
      바로..
      mount -a
      되겠습니다...
      문제 여부는 fstab 설정하기 강좌를 참고하세요..
      여기서는 설명하지 않고 fstab 파일에 문제가 있다는 상황을 가정합니다.


      그럼 fstab 설정파일의 문제가 발견이 되었다면 어떻게 하겠느냐....
      음... 리눅스 설치CD가 필요합니다....
      왜냐하면 CD로 부팅한후 복구모드를 통해서 해당 파일을 수정해야하기 때문입니다..

      참고로 뭐.. 부트로더가 날아갔거나 했을때도 지금부터 설명할 CD부팅복구모드 기능은 상당히 유용하게 쓰일 수 있습니다.

      복구모드로 들어가는 방법
      초기 리눅스 CD부팅 화면 (우리가 설치할때 linux 또는 text라고 입력하는 화면)에서..
      linux rescue
      라고 입력하면 됩니다.

      그러면 리눅스를 설치할때 나오는 화면들중 초반부분에 대한 내용이 거의 동일하게 나옵니다..
      복구모드에서만 나오는 내용 외에는 설명하지 않겠습니다.
      설치과정도 모르는 사람이 복구모드를 들어간다는게 말이 안되쟎아요...

      그리고.... 문제의 해결방법이 CD부팅만 있는것은 아닙니다.
      다른 방법들도 있어요...
      근데.. 왠지.. 나도모르게.... 그냥 CD부팅을 얘기하고 싶었어요....
      단지 그것뿐... 참 알아두면 유용하다는 이유도 있군요...


       

      2.1.1 네트워크 인터페이스(랜카드)

      장비에 랜카드가 존재하고, 부팅하는 리눅스CD의 커널이 이것을 인식할 수 있을경우 나타나는 화면입니다.
      복구모드로 들어가서 네트워크 연결이 필요한 경우에는 "YES"를
      지금 우리는 간단하게 파일수정만 하고 말테니까.. "NO"를 선택하면 됩니다.

       

      2.1.2 Rescue

      뭐... 설치된 시스템이 /mnt/sysimage 밑에 마운트되며...
      어떤 모드로 진입할것인지를 묻는 화면이 나옵니다..
      - Continue : 일반적인 모드로서... 설치된 리눅스를 /mnt/sysimage 아래에 마운트
      - Read-Only : 설치된 리눅스를 /mnt/sysimage 아래에 마운트 하나 읽기만 가능하게 마운트함
      - skip : 설치된 리눅스에 대한 마운트를 진행하지 않고 그냥 복구모드로 진입
       
      "Read-Only"를 제외하고 어느것으로 선택해도 무방하지만..
      우리는 "continue"로 갑니다..
      왜냐고...? 휴......!!!!
      선택하고 넘어가면... 잠시동안 시간이 흐른후... "니 시스템이 마운트 되었다" 라고 나옵니다..
      /mnt/sysimage 밑으로 마운트 되었으니..
      니가 설치한 리눅스를 루트로 사용하고 싶다라고 하면...
      그러니까..
      /mnt/sysimage 아래에 니가 설치한 리눅스 / 가 존재하므로...
      설치된 리눅스의 위치라 /mnt/sysimage/가 아닌 /로 사용하고 싶다라고 한다면
      "chroot /mnt/sysimage"명령을 실행하라는 의미입니다...
      "OK"를 누르면 쉘 화면이 나옵니다...


       

      2.1.3 쉘진입

      자 이제 /etc/fstab파일을 수정합니다.
      파일은 어디에 있냐면..
      아가 설치된 리눅스의 / 가 /mnt/sysimage/ 가 되었으므로..
      /mnt/sysimage/etc/fstab 파일을 수정하면 됩니다..
      어떻게 수정하는지는 역시 지난 강좌에 있으므로 여기서 언급할 필요도 가치도 시간도 의미도 없습니다..

      올바르게 수정을 마쳤다면.... 걍 리부팅하면 끝입니다...
      여기까지 설명한 내용의 의도는 문제가 발생했을 경우 해결을 위해서 CD를 이용한 복구모드의 부팅입니다...






       

      2.2 파일시스템의 오류 와 하드디스크의 결함

      디스크쪽의 에러가 발생할 경우에도 역시 Control-D 화면이 나타날 수 있습니다..
      위에서 설명한것처럼 어차피 디스크를 마운트하는 과정에서 문제가 발생하면 이 화면이 나타난다고 설명한바 있으니까요..
      그런데 fstab 수정과실의 경우와 차이가 있다면.. 이것은 사전 징후를 나타낸다는 점입니다.
      아마도 여러분이 서버관리를 하게된다면 초기 한두번 내지는 없을수도 있는 fstab의 오류에 의한 것보다
      하드디스크에 관련된 문제가 발생해서 Control-D 화면을 보는 횟수가 점점더 많아지게 될것입니다.

      여기서 하나... 파일시스템의 오류와 하드디스크의 결함은 엄연히 틀린것이 아닌가 하는 질문의 갖게 될 수 있습니다.
      맞습니다. 두개는 엄연히 개념상으로 틀리지요.. 전자는 논리적이고.. 후자는 물리적이다 라는 정도?
      하지만 fstab에서 지정한 장치를 어떤 원인에 의해서 올바르게 마운트할 수 없게 되었다는 점에서 공통점이 있고.
      무엇보다 이 두가지는 실제로 들여다보지 않으면, 그리고 경험이 없으면 정확히 판단하는것이 불가능하기 때문입니다.

      우리가 이런 상황에 봉착하게 되는것은 역시 갑작스러운 서버의 다운으로 리부팅을 실행했을 경우가 많습니다.
      다운된 서버에 콘솔을 연결해서 확인하면..
      ext3_error, 내지는 filesystem error 와 비슷한 문구들을 좍~ 뿌리면서 죽어있는 경우가 되겠지요..
      물론 이런 사전징후 없이 의도된 리부팅을 하는 경우에도 문제를 가지고 있었다면 똑같이 발생할 수도 있습니다..
      역시.. 다양한 서버를 운영해보면서 경험으로 판단하는것 밖에는 방법이 없다고 말씀드리고 싶군요..

      지금 부터 설명하는것은 절대적인 것은 아닙니다.
      제가 업무를 수행하면서 경험적으로 느낀것을 방법론으로 기술한 것으로서 이견이 충분히 발생할 수 있습니다.

      자.. 제가 이런 경우에 봉착했을때의 마음가짐 순서는 대략 이렇습니다.
      - 단순히 파일시스템 오류였으면 좋겠다. (최상의 시나리오)
      - 단발성이었으면 좋겠다.
      - 케이블 문제였으면 좋겠다.
      - 시발... 하드디스크 문제구나. (최악의 시나리오 = 결국 개고생)
      이렇게 되겠습니다.

      이건 뭘 의미하냐면...
      문제가 닥쳤을때, 기본적으로 파일시스템오류 부터 최악의 상황인 하드디스크의 결함까지는 모두 고려를 해야합니다.
      하지만 애석하게도 이걸 단번에 알 수 있는 방법이란 없습니다. 뭐.. 알 수 있는 관리자가 있을 수 도 있습니다. ;;;
      때문에 가벼운 문제부터 최악의 상황까지는 전개될 수 있다는 시나리오를 고려하고나서
      비교적 손쉬운 상황에대한 처리를 차례로 진행해보면서 상황을 판단하자는 것이죠


       

      2.2.1 파일시스템체크 (fsck)

      지난 시간에 한번 언급한적이 있습니다.
      파일시스템 체크를 하기 위해서는 fsck 라는 명령어를 사용한다고...
      파일시스템의 에러가 발생했을 경우 체크하고 바로잡는 역할을 하죠.
      파일시스템의 타입에 따라서 체크하는 방법이 약간씩 틀린데요...
      지금은 ext3 타입일 경우를 가정하고 설명하겠습니다.
      다른 타입에 대해서는 강좌보다는 간단한 팁설명을 나중에... 아주 나중에~ 기억나면 하겠습니다.

      파일시스템 체킹이라는것은 하드디스크가 인식이 된다는 가정 아래에서는 가장 기본적인 수행절차 입니다.
      위에서 ext3 타입을 가정한다라고 했지만...
      본 작업을 수행해야할 서버의 파일시스템이 어떤것인지는 확인을 해야합니다.
      혹시 다른 타입의 파일시스템이라면 실행법이 틀려지니까요.. 

      root@ns1:~
17:25:20 # cat /etc/fstab
/dev/hda2       /               ext3    defaults    1 1
/dev/hda1       /boot           ext3    defaults    1 2
none            /dev/pts        devpts  gid=5,mode=620  0 0
none            /dev/shm        tmpfs   defaults    0 0
none            /proc           proc    defaults    0 0
none            /sys            sysfs   defaults    0 0
/dev/hda3       swap            swap    defaults    0 0
/dev/hda5       /var            ext3    defaults    0 0
/dev/hda6       /tmp            ext3    defaults    0 0
/dev/hda7       /home           ext3    defaults    0 0
/dev/hdb1       /home2          ext3    defaults    0 0

      바로 /etc/fstab 파일을 확인해보는 것입니다.
      의도한 것이긴 하지만.. 본 서버에서의 파일시스템은 모두 ext3 를 사용하고 있습니다.
      추가로 어디에 문제가 발생한 것인지 모른다는것도 가정합니다.

      이제 fsck를 돌려 봅시다~

      root@ns1:~
17:29:27 # fsck -t ext3 /dev/hdb1
fsck 1.39 (29-May-2006)
e2fsck 1.39 (29-May-2006)
/dev/hdb1 has been mounted 122 times without being checked, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/hdb1: 1900766/30539776 files (0.3% non-contiguous), 32989359/61049000 blocks

      fsck -t ext3 /dev/hdb1
      이런 내용의 명령어를 사용했습니다..
      자.. 그럼 대략들 눈치는 다 까셨겠습니다만... 설명해 보지요..
      fsck 라는 명령어를 실행한다...
      어떻게?
      -t ext3 : 파일시스템 타입은 EXT3
      /dev/hdb1 : 체크할 디바이스명
      이렇게 되겠습니다...

      그럼 예제를 기반으로 문제가 발생했을경우.. 파일시스템 체크를 하는 방법은...

      # fsck -t ext3 /dev/hda1
# fsck -t ext3 /dev/hda2
# fsck -t ext3 /dev/hda5
# fsck -t ext3 /dev/hda6
# fsck -t ext3 /dev/hda7
# fsck -t ext3 /dev/hdb1
      이렇게 진행을 하면 됩니다.. 한마디로 /etc/fstab 에 기록된 디바이스를 모두 해주는 것입니다.

      왜 모두 해주냐구요?
      음.. 그것은... 어떤 디바이스에서 문제가 발생했는지 알 수가 없기 때문입니다..
      물론~ 서버가 다운될 당시에 발생한 메세지를 확인했다면 어느 디바이스의 문제있지 볼 수 있겠으나..
      역시 이 글을 봐야하는 그대라면..
      그리고 죽은 서버 앞에 서있다라고 가정한다면...
      분명 그 메세지를 보지 못했거나 봤어도 어떤게 중요한지 기억을 못하고 있을 것이라고 판단했기에
      다 진행하라고 하는 것이라는...


      자자 그럼 전체를 다 돌리는 과정에서 실제로 문제가 발생한것은 /dev/hda2 장치라고 가정합시다.
      그러면 fsck 명령을 수행중에 아래와 같은(똑 같지는 않고 비슷한) 화면을 만나게 될것입니다.

      root@ns1:~
17:29:27 # fsck -t ext3 /dev/hda2
fsck 1.27 (8-Mar-2002)
e2fsck 1.27 (8-Mar-2002)
/dev/hda2 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 4427809 is in use, but has dtime set. Fix? yes
Inode 4427810 is in use, but has dtime set. Fix? yes
Inode 4427810 has imagic flag set. Clear? yes
Too many illegal blocks in inode 4427819.
Clear inode? yes

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/: ***** FILE SYSTEM WAS MODIFIED *****
/: 106710/794976 files (0.9% non-contiguous), 1204013/1588426 blocks

      지금 설명한 예제에서는 Fix? Clear? 라는 질문에 모두 yes 라고 지시를 내린것입니다.
      그래야 파일시스템 체킹중 문제가 발생한 부분을 처리해 주거든요...

      그런데....
      예제에서는 에러가 별로 없어서 기껏해야 4번 정도의 입력밖에 해주질 않았는데요..
      만약 무진장 많이 물어본다면..
      실제로 수천번 이상 물어보는 경우도 있습니다..

      그러면 이걸 수천번을 y 를 입력해서 처리를 해줘야만 할까요????
      원론적으로 문제해결을 위해서 입력을 하기는 해야하는데...
      일일이 y를 입력하지 않아도 y가 입력된것처럼 처리할 수 있습니다.

      # fsck -t ext3 /dev/hda2 -y

      바로 -y 라는 옵션입니다..
      이걸 추가해서 실행하게되면 modify 진행 여부에 대한 이벤트가 나올경우 모두 yes로 처리한다는 의미입니다.
      아주 쓸만한 옵션이므로 반드시 기억해 두도록 합시다~


      /: ***** FILE SYSTEM WAS MODIFIED *****
/: 106710/794976 files (0.9% non-contiguous), 1204013/1588426 blocks
      대체로 이런식의 결과로 마무리가 되었다면 문제가 해결되는 경우라고 볼 수 있겠습니다.

      모두 실행후...
      프롬프트에서 "Control-D"를 누르면 리부팅을 진행합니다...

      정상적으로 리부팅이 된다면 끝인거죠...
      이런 경우는 대체로 파일시스템측의 문제가 발생한것이고...
      같은 상황이 재발하지 않는다면 심각한 문제는 아닙니다...



       

       

      2.2.2 하드디스크의 결함

      이번 내용은 대략적인 예를 들 수는 있지만..
      상황을 다 설명할 수는 없습니다.
      워낙 다양하게 문제가 발생하기 때문.... 사례를 일일이 다 적기도 귀찮고... 기억도 얼마 나지 않습니다....
      그냥 저럴 수 있구나 정도로 훑어보면 될듯 하군요...
       

       
      2.2.2.1 하드디스크가 인식되는 상황
      • Control-D 화면이 나와서 fsck를 진행하는 상황이 반복될경우
      • fsck를 진행하고 나니 파일구조가 개판된경우
        이경우 숫자로된 디렉토리가 졸라 많이 생기며.. 원래 있던 데이터 구조가 없어(?)짐


         
        • 2.2.2.2 하드디스크가 인식되지 않는 상황

        fsck 를 실행했을때 아래와 같이 나온다면.. 그리고 지정한 디바이스가 정확하다면..
        이건 하드디스크를 인식하지 못하는 경우입니다.
        장치가 없으니 점검할 것도 없는것이죠...
         

        root@ns1:~
14:31:31 # fsck -t ext3 /dev/hda2
fsck 1.35 (28-Feb-2004)
e2fsck 1.35 (28-Feb-2004)
fsck.ext3: No such file or directory while trying to open /dev/hda2

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

        이런 경우에는 몇가지 원인이 있을 수 있습니다.
         

        • 파티션이 날아간경우
          다른 파티션들은 멀쩡하게 있는데 특정 파티션의 파일시스템이 싹~ 사라지고 초기화된 경우
        • 하드디스크의 수명이 다한경우
        • 케이블에 문제가 발생한경우
        • 보드의 장치포트에 문제가 발생한경우
        • 하드디스크의 연결포트가 손상된경우


           
          • 이번 장에서는 Control-D 화면에 관련해서 설명한 것이기 때문에 이정도만 알아두면 될것 같아요.
           

          3 마무리

          Control-D 화면이 발생할 수 있는 상황과..
          어떻게 처리를 하면 좋을지를 설명해 봤습니다...
          각 기능에 대한 설명은 어려운게 아니지만..
          이것을 상황으로 묶어서 얘기하려니까...
          뭐랄까...
          좀 산으로 고고싱 하는 느낌이랄까???
          그런 생각이 들더군요...
          허나 각 명령어의 사용법 같은것은..
          책으로도 존나게 많이 나왔고.. 하다못해 인터넷에서 찾아봐도 다 있습니다..
          그냥 이번장을 쓰면서 나타내려고 했던 무언가는...
          관련된 내용을 상황으로 풀고 싶다는 것이 주된 목적이었네요..
          써 놓은글을 다시 읽어보니...
          ㅋㅋㅋㅋㅋ
          라는... -_-;;;;;
          암튼 참고가 초큼 되었으면 좋겠다는...
           
이 게시물을
이 글의 추천인 목록 게시글 수정 내역 수정 삭제 목록
번호 제목 글쓴이 날짜 조회 수
4 FTP 상태코드 위대한유저 2009.08.28 78636
3 HTTP 응답코드 위대한유저 2009.04.02 64576
» Control-D 화면에 대한 고찰 위대한유저 2009.03.13 43835
1 /etc/fstab 설정하기 [1] 위대한유저 2009.01.29 234418
쓰기 태그
위로