몽고 클러스터를 구축하기 위해 docker-compose로 컨테이너를 실행하고자 했으나 worker5desk 노드에서 치명적인 결함들이 속속히 발견됐다.
네트워크는 불안정 했고, journalctl이 원인으로 추청 되는 디스크 보호 모드 작동 등 많은 일들이 어제 새벽 동안 발생했다. 사실 그동안 프로젝트가 끝나고 해당 노드는 계속 재시동 한번 없이 계속 꺼뒀던 상태 인지라, 갑작스럽게 여러 문제가 겹쳐 발생하니 당황스러웠다.
시작은 간만에 킨 가상머신 안에서 docker-compose를 실행시키기 전에 발생 했는데 Read only File System으로 변한 것은 docker network create 명령어를 실행시키면서 알게 됐다. 언제부터 해당 디스크가 보호모드로 작동됐는지 확인하기 위해선 마운트된 디스크 파티션 중 어떤 것이 ro(read only)로 바꿔어져 있는지 알아야 했다.
그럼 그전에 리눅스 파일 시스템을 보자면
지금은 다행스럽게 /dev/sda2 파티션이 rw(read,write)모드로 작동되고 있다.
cat /proc/mounts | grep /dev/sad2 명령어를 통해 찾아봤을 때 문제가 발생되면 /dev/sda2 디스크 파티션이 ro 모드로 작동이 된다. 그러면 이제 우리가 실행하고자 하는 작업에서 read only file system이라는 오류가 발생하면서 실행이 중지가 되는 것이다.
cat /proc/mounts | grep /dev/sad2 명령어를 통해 찾아봤을 때 문제가 발생되면 /dev/sda2 디스크 파티션이 ro 모드로 작동이 된다. 그러면 이제 우리가 실행하고자 하는 작업에서 read only file system이라는 오류가 발생하면서 실행이 중지가 되는 것이다.
** /dev/loop? 루프 디바이스.
/dev/sda란 리눅스 상에서 디스크를 명명하는 규칙에 따라 이름이 붙는 것인데, sd는 리눅스 상에서 디스크를 뜻한다. 이 뒤에 윈도우의 C:\ 혹은 D:\ 처럼 가장 처음에 생기는 디스크를 a로 해서 b,c,d, … 이런 식으로 디스크가 만들어지게 된다. 이때 해당 디스크의 파티션 순서를 1부터 시작하는 숫자로 명시하게 되는데 위에 사진을 보면 우리 서버 컴퓨터의 디스크는 약 64GB 짜리 a디스크에 하나의 파티션에 데이터가 들어가 있는 것을 확인 할 수 있다. (왜 sda1이 아닌 sda2인지는 잘 모르겠다, 아마 sda1에는 bios시스템이 들어가 있는게 아닐까.. OS를 설치할 때 그렇게 봤던 것 같기도 하고..)
오류가 났다..Read only File System…!
즉, OS상에 존재 하는 모든 파일과 데이터가 저 sda2 디스크 파티션에 들어가 있을텐데, 이 디스크가 읽기 전용 모드로 바뀌니 아무 작업도 할 수 없는 상황이 되는 것이다. 그렇다면 왜 이런 문제가 발생을 하는지, 해결할 수 있는 방법이 있는지 먼저 알아볼 필요가 있다.
- 해당 디스크 사용률이 높아졌기 때문에 더이상 디스크에 새로운 쓰기 작업을 실행 할 수 없게 되어 이제는 읽기 작업만 수행하도록 보호모드가 작동 되는 경우
- 디스크가 손상되어 더이상 쓰기 작업을 실행할 수 없는 경
- 파일 시스템을 지정하고 파티션을 포맷하고 사용해야 하는데 그렇게 하지 않아 텅 빈 파티션을 사용하고자 하는 경우
내가 보고 경험한 사례 들을 봤을 때 이 3가지 정도로 추려지는데(이 밖에 케이스는 더 많을 것이라 생각된다.), 이번에 내가 경험한 사례의 경우 2번에 해당되는 경우로 보여진다.
systemd-journald[400]: Failed to write entry (22 items, 1025 bytes), ignoring: Cannot assign requested address
여기서 나오는 journald는 우분투의 systemd에서 서비스 로그를 남기는데 이때 로그를 journal이라는 바이너리 파일로 남긴다. 그런데 이게 디스크 읽기 전용 모드로 바뀌게 되면서 저널링을 수행할 수 없어 이렇게 오류가 발생하는 것이다.
sudo journalctl —verify 를 찍어보면 어느 파일들이 말썽을 부리고 있는지 확인 할 수 있다.
해당 오류의 정확한 원인을 찾을 수는 없었고, 저널로그들이 쓰일 때 어떤 원인이 발생하여 저널 파일을 쓸 수 없든, 손상이 됐던, 파일이 충돌이 났든 해서 오류가 발생한다고 추정할 수 밖에 없었다.
사진에는 디스크 사용량이 16%정도로 찍히지만 원래 디스크 사용량은 이것 보다 훨씬 많았다. 아무튼, 결국 지금 디스크에서 문제가 발생했다고 생각했고, 저널 데몬이 비정상적인 활동을 하고 있다는 사실도 발견했다. 이에 두 가지 해결 방안을 생각해낼 수 있었는데,
- 디스크 사용량을 줄인다.
- 저널 파일들을 대거 삭제 한다.
하지만 두 방법 다 읽기 전용모드 였기 때문에 진행할 수 없었다. 그럼 일단 디스크 문제해결 복구 명령부터 진행하기로 했다.
sudo umount /dev/sda2 명령어를 통해 문제가 발생하는 디스크 파티션을 마운트 해제 시킨 다음e2fsck /dev/sda2 라는 명령어를 통해 디스크를 점검하고 손상된 파일 시스템을 복구 시킬 수 있도록 했다. 이후sudo mount -o remount, rw /dev/sda2 라는 명령으로 rw 모드로 마운트를 시킨 뒤, 변경 사항이 적용될 수 있도록 sudo reboot 로 재시작 했다.
이게 만능 처방은 아니다. 하지만 당장 디스크 보호모드만 해제 시킬 수 있다면 일단 디스크 파일 정리를 할 수 있기 때문에 이렇게 진행했다. 그리고 다행히 리부팅 된 이후엔 잠시동안 디스크 보호모드가 해제 된 것을 확인할 수 있었고, 황급히 디스크를 정리하고자 했다. /var/log 디렉토리에 들어가면 systemd의 저널로그 말고도 수많은 시스템에서 남겼던 로그 파일들이 많이 남아 있었다. 함부로 지우면 안되는 것은 맞으나 내가 설치 후 삭제한 프로그램들이 남겼던 로그 디렉토리는 남김없이 지웠다.(나머지는 이것저것..) 이후 저널 파일을 정리하기 위해
- journalctl --vacuum-files=10 : 저널 파일을 10개 이하로 관리한다.
- journalctl --vacuum-time=1d : 오늘 기준 과거 1일 전까지의 저널 파일만 저장한다.
라고 명령을 해서 저널 파일을 정리하고자 했다. 그리고 다시 리부트. 켜보니 일단락 된 것 같다. 다행 스럽게도 한동안 read only file system오류는 나지 않았다.
이번엔 네트워크가 이상하다…!
해당 서버 작업은 노트북으로 ssh 접속하여 작업하고 있었고, 중간 중간 꽤 긴 딜레이가 발생하고 있었는데, 이를 서버가 불안정하니.. 하며 대수롭지 않게 생각했고 넘겼다. 읽기 모드를 해제하기 위해 고군분투 하고 있었던 중 이여서, 이를 생각해볼 여유가 없었던 것 같다.
아무튼, 이제 어느 정도 일단락 된 상황에서 이제 눈에 밟히는 것은 불안정한 네트워크 연결 이였다.
단순히 와이파이에 이상이 있다고 생각했으나, 집에서도, 밖에서도 어디서든 연결이 불안정한 상태로 지속됐다.
그러다가 갑자기 virtual box의 호스트 네트워크 어댑터를 봐야겠다는 생각이 스쳐 지나갔고, 이때 기존 네트워크가 대역에 맞지 않아서 생긴 문제였던 것으로 추정됐다. 결국 Host only network adapter를 수정하고 나니 대역대가 192.168.56.1 에서 192.168.181.1로 수정이 됐고
DHCP설정을 완료 하고 나니 네트워크가 정상적으로 통신됐다. 아직도 그 명확한 원인은 파악하지 못한 채로 사용 중인데, 네트워크에 대한 공부가 정말 필요하다고 생각됐다. 정말 네트워크는 알다가도 모르겠다.
끝으로
하루를 꼬박 밤 새워 결국 가까스로 정상화 시켰다. 좋은 경험 이였으나, 아는 것이 없으니 하나의 오류에 대응 시 심적으로 여유가 없어지는 기분 이였다. 알 수 없는 것들을 배울 수 있다는 경험은 값진 것 이였으나, 상황이 닥쳤을 때는 울 뻔 했다.
안정적인 인프라를 설계하는 것이 중요하다고 생각 했고 다음에는 가용성이 좋은 인프라를 설계하고자 하는 노력을 해본 경험을 써볼까 한다.
네트워크는 불안정 했고, journalctl이 원인으로 추청 되는 디스크 보호 모드 작동 등 많은 일들이 어제 새벽 동안 발생했다. 사실 그동안 프로젝트가 끝나고 해당 노드는 계속 재시동 한번 없이 계속 꺼뒀던 상태 인지라, 갑작스럽게 여러 문제가 겹쳐 발생하니 당황스러웠다.
시작은 간만에 킨 가상머신 안에서 docker-compose를 실행시키기 전에 발생 했는데 Read only File System으로 변한 것은 docker network create 명령어를 실행시키면서 알게 됐다. 언제부터 해당 디스크가 보호모드로 작동됐는지 확인하기 위해선 마운트된 디스크 파티션 중 어떤 것이 ro(read only)로 바꿔어져 있는지 알아야 했다.
참고 자료
[pi] Read-only file system 오류 해결
Read-only file system 에러가 발생해서 디스크 작업이 안 되네요.
https://www.linuxadictos.com/ko/solucion-al-error-read-only-file-system.html
Ubuntu(리눅스) Read-only file system 에러
Read-only file system. 수업 진행을 못하고있습니다! 도와주세요! ㅠㅠ | 코드잇
Crash: systemd-journal Failed to write entry. Ignoring: read-only file system only
'Projects' 카테고리의 다른 글
| [Ciaolabella] 디스크가 점점 쌓인다...! (0) | 2023.01.29 |
|---|---|
| [Ciaolabella] 회고 - 2022년 마지막 프로젝트를 끝내며.. (0) | 2023.01.03 |
| [회고] 봉사 활동 기간에 크롤링으로 업무 자동화를 구현해본 일 (0) | 2022.12.09 |