리눅스 기반 OS에서 로그 파일이 가득차면 부팅되지않거나 로그인이 안되거나 불안정한 증세가 있는지 궁금합니다.

   조회 5760   추천 0    

안녕하세요!

리눅스 기반 OS[ 예) xpenology ]에서 계속 생성되는 log로 인해

log파일 크기가 몇 년에 걸처서 시스템 파티션(또는 /var)을 빈공간 없이 가득차게 만들면,

이로 인해 부팅되지 않거나, 로그인이 안되거나, 불안정한 문제가 생기는지 궁금합니다.


ESXI에서 windows 10 VM을 사용했는데 파티션에 빈공간이 없으니 VM을 켜지조차 못하는 일을 겪은 적이 있었습니다.

Q1> 그래서 리눅스에서는 어떤지 궁금합니다.

xpenology에 대해서 잠시 설명을 하자면 이렇습니다.

xpenology는 synology DSM을 일반PC에 사용할 수 있도록 개조 한 OS입니다. (사용할 수 없는 부분을 짜집기 하여 되도록 만들어졌습니다.)

그래서 synology 시스템에서 사용되는 독자규격 장치(OEM 칩셋등)는 일반PC에서는 사용되지 않기에

일반PC에 xpenology를 설치하면 xpenology에서는 본질적으로 쓸모없고 관리할 수 없는 오류 로그가 많이 발생합니다.

(예: LED인디케이터 오류 발생, FAN경고 알림, SMART 디스크 info 관련 오류 로그, 캐시모니터 오류)

이 예시의 로그가 본질적으로 쓸모없고 관리할 수 없는 오류 로그① 입니다.

---① 이러한 오류들은 특정한 경우에 나타난 것이 아니고 대부분의 xpenolgoy사용자에게 발생할 수 있습니다.

---"SMART 디스크 info 관련 오류 로그"에 대해 설명 하자면, ESXi에서 동작시 VMDK 가상디스크의 SMART 정보를 불러올 수 없기에

---smart오류가 초단위로 생성되지만 이 로그는 시스템 동작에는 아무런 영향이 없습니다.


xpenology DSM에서는 지금도 /var/log/messages에 수많은 로그를 기록하고 있습니다.

/var/log/messages 이 위치 뿐만 아니라 다른 장소에도 기록되고 있습니다.

예) 커널 이벤트는 커널 로그 및 syslog 기본값에 독립적으로 기록


이러한 로그들로 인해 xpenology의 "4GB" 가량의 작은 시스템 파티션 공간이 가득차게된다면

제목에서 말한 문제가 발생하지 않는지 알고 싶습니다.

Q2> 리눅스와는 다르게 xpenology에서는 어떻게 될지 궁금한 부분입니다.(xpenology는 시스템OS적인 부분도 리눅스와 호환되는 것이 아닌 독자적인 다른 구조를 사용하는 부분이 있다고 생각해서 이 질문을 드렸습니다. )


Synology DSM은 매 초마다 잠잠해짐 없이 줄기차게 나오는 로그를 염두해 두지는 않고 시스템을 만들지 않았을까 생각합니다.

Q3> synology DSM 개발자들은 이러한 로그를 처리할 방안을 만들었을지 궁금합니다.

저는 리눅스에 대해 깊은 지식을 가지고 있지 않습니다. 그래서 궁금해서 이러한 질문을 하게 되었습니다.

전문가 적인 시점에서는 어떻게 보시는지 알고 싶습니다.


Q4> synology DSM이 알아서 로그가 너무 길면 용량 줄이고 관리 하는 것인지도 궁금합니다.


hi
짧은글 일수록 신중하게.
epowergate 2020-07
Linux라면 log rotate 설정하시면 됩니다
그런 이유로 보통 로그는 별도 파티션에 저장합니다
시도니 2020-07
/var 디렉토리 자체가 boot에 영향을 주지는 않습니다.

하지만, 최근 os 경향을 보면 스토리지 자체를 볼륨그룹으로 두고,

제일 중요한 /,swap 혹은 /export or /home 정도를 빼고 나머지는 / 에 붙여버립니다.

즉, /var 가 차게 되면 / 에 용량이 가득차게 되니까 부팅이 안될 수도 있게 됩니다.

물론 / 도 가득찬다고 해서 100% 부팅 안됨은 아닙니다.

하지만 매우 큰 충격은 줄 수 있지요.
     
hana76 2020-07
말씀하신대로 생각해보니 동의하는 부분이 있습니다.
제가 SSD에 파티션 할 때에
총공간 40GB일 때
( "/" 파티션 36GB)
( swap 파티션 4GB)
이렇게 2개의 파티션만 생성했습니다.
그렇다면 "/var"은 (swap파티션 처럼 리미트가 걸려 있지 않고) "/"의 공간을 다 사용할 수 있을 것이라 생각됩니다.

그러면 2가지 생각이 떠오르는데
시나리오 1>
( "/" 파티션 36GB)
( swap 파티션 4GB)
이렇게 구성했을 경우 "/var"이 "/"의 빈공간을 엄청난 로그파일로 인해 "0"으로 만들어 부팅조차 안되거나 로그인이 안되거나 불안정해지는 문제가 생길 수 있다.

시나리오 2>
( "/" 파티션 30GB)
( "/var" 파티션 6GB)
( swap 파티션 4GB)
이렇게 구성했을 경우 "/var"의 빈공간은 "0"이 되어도 추가적인 로그만 기록하지 못할 뿐 "/"에는 여유공간이 있으므로 정상적인 동작이 가능하다.

Q1> 이렇게 시나리오 2가지를 생각해 봤는데 맞는 것일까요?

Q2> "시나리오2"의 경우 log를 더 이상 기록할 수 없을 경우 버벅임 같은 문제가 발생 할까요?
          
시도니 2020-07
아까 말씀드렸지만 /가 full이 난다고 해서 100%부팅이 안되는 것은 아닙니다.

부팅이 시작되는 순서는 장치드라이버를 kernel로 실어 올린 후에 서비스를 기동하는 절차에서 몇몇의 프로그램들은 로그작성 불능 상태에서도 메인 프로세스 동작과는 상관없이 동작하는 어플들이 있습니다.

대체적으로 unix-like 시스템들은 추적의 용이성을 위해 프로세스를 파일에 기록하는 경우가 있는데 완전히 0이 되면 이 기록을 못하게 되 마치 hang이 되는 어플들도 았습니다.

원칙적으로는 /var 뿐만이 아니라 다른 디랙토리까지 모두 항시 추적하고 있어야 합니다.

하지만 그것이 꼭 log가 아닐 수도 있기 때문에 전체 디랙토리 단위로 용량 top 을 sorting 해서 본다던가 가장 큰 파일이 무엇인지 찾아보는 행위는 지극히 당연한 것입니다.

결론적으로 시스템의 특성은 다 다르므로 사용자가 파악해야 합니다.

왜 다둘 /var 나 log를 이야기 하시냐면,... 그것들이 어떤 중요도 때문보다 사용자가 예상하지 못했던 혹은 잠시잠깐 방심하는 사이에 어떤 특정한 상황을 만나서 폭주하듯 용량을 써버릴 수도 있기 땨문입니다.

따라서 맨 위에 epowergate님이 언급하신 것 처럼 파일을 어느 적정수준으로만 기록을 하던가 얼마씩 자르되 최대 몇개까지 보관하도록 설정하시거나 cron에 등록하시라고 권장드리는 겁나다.
제온프로 2020-07
로그로 인하여 시스템 드라이브가 꽉 차면 부팅을 못합니다...

각 프로그램 마다 로그 유지를 1개월 할 건지 , 10GB 할 건지
한계가 있을 겁니다...

예전에 Apache Access.log + Error.Log 가 하드에 꽉차서
부팅은 됬는데.. Apache가 실행을 못 해 버리더군요...
BSDKernel 2020-07
그냥 설치만 해놓고 사용하다가 var이 다차서 공간이 부족할것 같으면 경고 메시지가 떠줍니다...

근데 보통은 /var이 다 차기 전에 OS를 재설치하곤 해서....별 문제가 없었는데...

저용량 SSD에 공간 절약을 위해 용량을 적게 잡아두면...간혹 경고 메시지가 뜨긴 하더군요..

경고 메시지가 뜰때쯤이면 체감할정도로 속도가 느려지고 그랬었습니다....

써놓고 보니 이건 FreeBSD에서 경험한거고...파일 시스템을 /, swap, /var, /tmp, /usr로 미리 나누어서 설치한 경우입니다...


QnA
제목Page 2474/5722
2015-12   1753892   백메가
2014-05   5226441   정은준1
2006-04   5720   이문흠
2012-07   5720   미수맨
2016-10   5719   유혹낚시꾼
2007-09   5719   김석한
2008-07   5719   김희종
2012-10   5719   회원K
2015-04   5719   acarin
2019-06   5719   새로운차원
2008-02   5719   김백균
2016-01   5719   시노노
2008-05   5719   이문흠
2020-06   5719   키가180
2022-08   5719   봉래
2013-01   5719   김건우
2018-02   5719   백만스물하나
2015-04   5719   우렁
2013-01   5719   jabez033
2009-04   5719   Turtleship
2013-03   5719   스카이
2008-10   5719   임진욱