임시폴더 관리
한국의 모 클라우드 서비스를 이용중. 어젯밤 마주한 상황
서비스 관리 웹페이지에 접속하여, 서버리스트에서 시작 버튼을 누름, 상황판이 “사용”으로 바뀐후에도 ssh 접속되지 않음, 재시작버튼을 누르면 ssh 접속이 됨, 하지만 동작을 시작한지… 10분쯤 지나면 다운됨.
내가 리눅스를 삐꾸로 배워놓은지라, 어디를 봐야하는지 짐작도 못함. 그래도 주워들은 것이 있어 tail -f /var/log/syslog
를 해놓고, 10분을 기다림.
아싸, 이 파일이 맞구나, 서버가 다운될때 이런 로그를 뱉어내는 것을 확인함.
Nov 21 02:31:45 localhost kernel: [ 763.286109] WARNING: g.e. still in use!
Nov 21 02:31:45 localhost kernel: [ 763.286118] WARNING: leaking g.e. and page still in use!
Nov 21 02:31:45 localhost kernel: [ 763.286138] block xvdb: device/vbd/51728 was hot-unplugged, 1 stale handles
그런데… 응? 무슨 말인지 모르겠슴. 암튼 마운팅 되었던 녀석이 자동으로 풀린것 같음. 내가 해결할 수 없는 문제 같음. 고객센터에 문의남김. 이리저리 뒤져보는데…
이상하게 /tmp
폴더가 크기가 큼. 원래 /tmp
는 부팅하면 깨끗해지는 곳 아닌가? 들어가서 지우려는데 파일이 20만개쯤 있슴. 내가 만든 프로그램이 cron 따라 돌면서 쓰레기를 남겼슴. 삭제하려해도 너무 많아서 지능적으로 지워야하는 상황.
10분마다 다운되면 다시 켜고 파일들 삭제하면서 시간을 보내는데, 새벽 3시에 100으로 시작하는 번호에서 전화가 옴. 음… 역시 한국서비스를 이용하면 이런게 좋군.
답변 내용은 “콘솔에 이런게 찍혔는데, tmp 폴더 마운팅에 실패한것 같다, 스냅샷을 생성해서, 새로운 vm을 생성하고 그쪽에서 복구를 해보시라.” 는 내용이었다. 글쎄, 콘솔로그만보고 판단하시려니 힘드시겠지만… 일단 더 시도해볼만한 여지가 있지 싶음. 보내주신 콘솔 로그.
/dev/xvdb1: clean, 932573/5242880 files, 15339566/20971264 blocks
/dev/xvdb1: clean, 932573/5242880 files, 15339566/20971264 blocks
The disk drive for /tmp is not ready yet or not present.The disk drive for /tmp is not ready yet or not present.
Continue to wait, or Press S to skip mounting or M for manual recoveryContinue to wait, or Press S to skip mounting or M for manual recovery unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
일단 /tmp
를 깨끗하게 해주고, 혹시나 싶어 추가했던 디스크중에 하나를 연결해제 해줌. 이게 문젠데, /tmp
폴더에 too many files
가 문제인지, 디스크를 여러개 추가한게 문제인지 불확실해져버렸슴. (비슷한 문제를 겪을 분한테 도움되라고 끄적이는건데.. 우쨌든.)
비슷한 증상을 겪으시는 분은 일단 /tmp
를 청소하시고, 추가 디스크 연결된것들이 있으면 하나씩 연결해제해보시길.
남은 의문이 있는데…. “프로그램을 작성할때 /tmp
에 쓰레기를 만들곤하는데, 주기적으로 삭제해주지 않아 파일이 20만개정도 쌓이면 rebooting
시에 문제가 되나?” 하는 것. (참고로 ucloud 나 digitalocean이나 cafe24 tera 서버나 /tmp
는 tmpfs 가 아니었슴. 위키백과가 틀림?)