FTP로 파일 업로드 했는데 파일 크기가 0byte, mysql은 먹통 됐을 때 해결 방법

cafe24의 VPS의 경우이니 다른 서버에서는 일부 경로가 다를 수 있습니다.

열심히 프로그램 작업을 하던 중에 갑자기 파일 업로드가 안 된다. 파일은 생성 되는데 크기가 0byte로 내용이 없다. 직감적으로 서버에 문제가 생겼구나 생각은 들었지만 원인을 찾지 못해 애먹고 있었다. 지식인에도 관련 내용이 없다. 아는 상식 선에서 최대한 키워드를 생각해 내서 검색했지만 원인과 해결 방법을 찾지 못했다. 그러다 과거에 서버를 처음 공부 할 때 비슷한 경험이 있었던 걸 기억해 냈다. df -h를 실행하니 파일 하나가 use 100%로 되어 있는 걸 발견했다.
[root@wonjustory ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                       19G  15G   15G  100% /
/dev/vda1              99M   20M   75M  21% /boot
tmpfs                 249M     0  249M   0% /dev/shm
VolGroup00-LogVol00 이 놈이 뭔지는 모르겠지만 어쨌든 디스크를 100% 차지하고 있어서 더 이상 파일을 작성 할 수 없었던 원인 건 분명했다. 이게 뭔지는 몰라도 위에 Filesystem이라고 되어 있는 걸 알아차렸어야 했다. filesystem이나 link는 굵은 글씨라는 걸 깜빡했다. /dev/mapper 경로에 들어가니 VolGroup00-LogVol00, VolGroup00-LogVol01 두 개가 있었고 하나가 디스크  100%를 사용 중이였다. 미련 없이 rm VolGroup00-LogVol00를 하고 나서야 저것이 파일이 아닌 마운트라는 걸 알았다.
고객센터에 사정을 말하고 다시 백업본으로 서버를 복구해야 했다.
흔한 경우는 아니지만 누구나 이런 경우를 맞게 될 수 있다. 보통 운영하는 사이트가 번창해서 자료가 꽉 찼을 때이지만 error log 파일이 원인 일 수도 있다.
[root@wonjustory ~]# du -h / --max-depth=1
0       /net
8.0K    /opt
8.0K    /media
27M     /lib64
233M    /lib
14M     /boot
136K    /dev
............
15GB    /var
24K     /tmp
...........
100M    /etc
8.0K    /mnt
...........
8.0K    /srv
517M    /home
du 명령을 이용해서 각 디렉토리별로 사용량을 알아 볼 수 있다. 내가 이 명령을 실행 했을 땐 /var가 15GB를 차지하고 있었다. /var에 들어가 다시 du -h --max-depth=1 똑같은 명령을 실행 했다.
[root@wonjustory var]# du -h --max-depth=1
............... 8.0K    ./opt
8.0K    ./ftp
69M     ./lib
24M     ./cache
...................
8.0K    ./tmp
308K    ./run
20K     ./yp
15GB     ./log
8.0K    ./games
40K     ./lock
..................
8.0K    ./local
28K     ./db
1.2M    ./www
131M    .
경로에서 /가 빠졌다는 걸 유의하자. ./log 디렉토리가 15GB를 차지하고 있다. 다시 log 디렉토리로 들어가본다. ll 명령을 실행하면 log 파일들이 몇 개가 보인다.
access log 파일 5개, error log 파일 5개가 있었는데 그 중에 error_log라는 파일이 15GB를 넘게 차지하고 있었다. 저 파일을 삭제 했다. 서버를 재실행하고 죽어 있던 mysql 데몬을 다시 실행했다. 드디어 잘 돌아간다.
하루가 지나고 다시 작업하던 사이트에 접속하니 전날과 똑같은 오류가 생겼다. mysql이 먹통이 됐다. 같은 방법으로 log 파일을 확인하니 다시 15GB가 됐다. 도대체 뭔 내용인가 열어보니 php 실행 중 발생한 오류들이 들어 있었다. 여기서 내가 해결 할 수 있는 방법은 사이트에서 사소한 오류 조차 없도록 프로그램과 태그를 완벽하게 구현 해 놓던가 저 error_log 파일을 처리해야 했다. 삭제를 하거나 용량을 제한하는 방법이 있을 것이다. 나는 일단 생성 안 되도록 하는 길을 택했다.
[root@wonjustory var]# vi /etc/php.ini
php.ini을 열어보면 아래와 같은 헤더를 만날 수 있다.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Error handling and logging ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
딱 봐도 로그 관련 설정임을 알 수 있다.
; Common Values:
;   E_ALL & ~E_NOTICE  (Show all errors, except for notices and coding standards warnings.)
;   E_ALL & ~E_NOTICE | E_STRICT  (Show all errors, except for notices)
;   E_COMPILE_ERROR|E_RECOVERABLE_ERROR|E_ERROR|E_CORE_ERROR  (Show only errors)
;   E_ALL | E_STRICT  (Show all errors, warnings and notices including coding standards.)
; Default Value: E_ALL & ~E_NOTICE
; Development Value: E_ALL | E_STRICT
; Production Value: E_ALL & ~E_DEPRECATED
; http://www.php.net/manual/en/errorfunc.configuration.php#ini.error-reporting
error_reporting = E_ALL & ~E_DEPRECATED
짧은 영어를 동원해서 해석해 보자면 error_reporting는 PHP 실행 오류를 어디까지 보여줄 것인가 설정하는 부분이다.
; This directive controls whether or not and where PHP will output errors,
; notices and warnings too. Error output is very useful during development, but
; it could be very dangerous in production environments. Depending on the code
; which is triggering the error, sensitive information could potentially leak
; out of your application such as database usernames and passwords or worse.
; It's recommended that errors be logged on production servers rather than
; having the errors sent to STDOUT.
; Possible Values:
;   Off = Do not display any errors
;   stderr = Display errors to STDERR (affects only CGI/CLI binaries!)
;   On or stdout = Display errors to STDOUT
; Default Value: On
; Development Value: On
; Production Value: Off
; http://www.php.net/manual/en/errorfunc.configuration.php#ini.display-errors
display_errors = Off
; The display of errors which occur during PHP's startup sequence are handled
; separately from display_errors. PHP's default behavior is to suppress those
; errors from clients. Turning the display of startup errors on can be useful in
; debugging configuration problems. But, it's strongly recommended that you
; leave this setting off on production servers.
; Default Value: Off
; Development Value: On
; Production Value: Off
; http://www.php.net/manual/en/errorfunc.configuration.php#ini.display-startup-errors
display_startup_errors = Off 
아래로 내려오면 display_errors 이 항목이 있는데 PHP 실행 오류나 경고 내용을 화면에 보여 줄 것인가 설정한다. 홈페이지에서 실행 오류를 보여주지 않기 위해서는 off로 한다. display_startup_errors는 PHP가 실행되는 모든 과정 중에서 생긴 오류를 출력한다. 이 스위치를 ON으로 하면 개발하면서 디버깅에 유리하지만 에러 메시지 노출은 때로 환경 정보가 보여지기도 하기 때문에 보안에 좋지 않다. 이 설정들은 PHP.ini 뿐만 아니라 ftpaccess 파일이나 PHP 함수로 설정이 가능하다.
ini_set('display_errors', '1'); 
ini_set('error_reporting', E_ALL);
error_reporting(E_ALL); 
조금 더 아래로 내려오면 다음 항목을 볼 수 있다.
; Besides displaying errors, PHP can also log errors to locations such as a
; server-specific log, STDERR, or a location specified by the error_log
; directive found below. While errors should not be displayed on productions
; servers they should still be monitored and logging is a great way to do that.
; Default Value: Off
; Development Value: On
; Production Value: On
; http://www.php.net/manual/en/errorfunc.configuration.php#ini.log-errors
log_errors = On
PHP 실행 중 오류가 생기면 내용을 로그 파일에 기록 할 것인지를 설정한다. 이 스위치를 OFF로 하면 에러 로그들이 파일에 기록되지 않는다.
; Set maximum length of log_errors. In error_log information about the source is
; added. The default is 1024 and 0 allows to not apply any maximum length at all.
; http://www.php.net/manual/en/errorfunc.configuration.php#ini.log-errors-max-len
log_errors_max_len = 1024
log_errors_max_len는 로그 파일의 크기를 제한 할 수 있다. 이 밖에 몇 가지 에러 로그 설정을 할 수 있는데 파일을 생성하고 싶지 않을 때는 스위치를 Off로 설정하면 해결 할 수 있다. 프로그램 개발 중에는 오류 내용을 열람할 필요가 있으니 그 때는 ini_set('display_errors', '1');  함수를  내 아이피나 내 아이디에서만 작동하도록 해 두는 것이 좋다.
PHP에서 파일 쓰기가 안 되거나 FTP로 업로드를 했는데 파일 크기가 0byte라면 당황하지 말고 이 내용을 확인해 보자.
https://zibsin.tistory.com/2484

리눅스 서버, FTP 접속 했을 때 상위 경로(다른 계정) 디렉토리가 보이지 않게 하기