본문 바로가기
Programming/MySQL

[WSL] CentOS MySQL Error 2002 (HY000) /var/lib/mysql/mysql.sock 문제 해결

by 8ugust 2022. 1. 13.

$ mysql
ERROR 2002 (HY000):
Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)

 

 LEMP 환경을 구성을 마친 다음 날, PC에서 MySQL 실행 시 위에서 보이는 것과 같은 에러가 발생하기 시작했다. 원인 분석 및 문제 해결을 위해 디버깅을 시도하러  vi /var/log/mysqld.log  를 확인해봤지만, 방금 발생한 에러에 대한 로그는 없었다. 무엇이 원인인지는 단 한 번의 구글링을 통해 알 수 있었다. 바로 mysql 서버를 실행하지 않은게 원인이라고 했다.

 

 윈도우 시작 시 .bat 파일을 통해 LEMP 환경을 자동으로 시작하도록 설정했는데, 무슨 원인인지 서비스가 제대로 시작되지 않은 모양이다. 그래서 로그에 기록조차 되질 않았나보다. 이 부분에 대해서도 원인 분석을 시도해봤는데, WSL의 고질적인 문제라나 뭐라나... 그럴 때 마다 WSL을 종료 후 다시 시작하면 언제 그랬냐는 듯 문제가 사라지더라. 아무튼 다음의 명령어로 위 문제를 해결할 수 있다. 

 

systemctl start mysqld

 

$ mysql
ERROR 2002 (HY000):
Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (111)

 

 문제는 지금부터였다. 서비스가 동작(running) 상태인 걸 확인한 뒤 다시 MySQL을 실행해보았지만, 아까와 같으면서도 다른 에러를 내뱉는 상황이 발생했다. 디버깅을 위해 다시 한 번 로그를 확인했는데, 다행스럽게도 이번엔 서비스가 구동중인 상태라 로그가 정상적으로 기록되어 있었다.

 

$ vi /var/log/mysqld.log

.
.
.
[Note] IPv6 is available.
[Note]   - '::' resolves to '::';
[Note] Server socket created on IP: '::'.
[ERROR] Can't start server: can't check PID filepath: No such file or directory

 

 No such file or directory 에러. PID filepath에 문제가 있다고 한다.

 짧은 검색을 통해 .pid 파일의 경로는 my.conf 파일에 기재되어 설정된다고 한다.

 내 .pid 파일의 경로가 어디를 바라보고 있는지 확인하기 위해 해당 설정 파일을 열어보았다.

 

$ vi /etc/my.conf

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

 

 내 .pid 파일 경로는 /var/run/mysqld/myslqd.pid 라고 한다. 해당 경로에 내 .pid 파일이 실제로 있는지 확인해보니 .pid 파일은 커녕 myslqd 디렉터리 조차 존재하지 않았다. /var/run/ 하위 디렉터리에 mysqld 디렉터리가 아예 없었다. 뭔가 설정을 잘못 건드렸나 싶어 해당 디렉터리를 생성한 뒤, 소유자와 권한을 mysql로 변경하고 서비스를 재시작해보았다.

 

mkdir /var/run/mysqld

chmod 755 -R /var/run/mysqld

chown mysql:mysql -R /var/run/mysqld

 

 확인해보니 MySQL이 정상적으로 실행되었다. 이대로 문제 해결인가 싶었는데 아니었다. 여전히 WSL이 재시작되면 (111) 에러가 발생하며 MySQL 실행이 되질 않고 있었다. 디버깅을 위해 로그를 확인해보니 PID filepath: No such file or directory 로 아까와 같은 에러가 발생하고 있었고, 혹시나 싶어 확인해보니 /var/run/mysqld 디렉터리가 다시 사라지고 없었다.

 

 

$ vi /usr/lib/tmpfiles.d/mysql.conf

.
.
# You should have received a copy of the GNU General Public License along with
# this program; if not, write to the Free Software Foundation, Inc., 51
# Franklin St, Fifth Floor, Boston, MA 02110-1301  USA
d /var/run/mysqld 0755 mysql mysql  -

 

 찾아보니 /var/run/myslqd 디렉터리는 임시로 사용되는 디렉터리로, /usr/lib/tmpfiles.d/mysql.conf에 기재되어 있는 설정에 따라, /var/run/mysqld 디렉터리가 존재하지 않으면 소유 및 권한 mysql 과 0755 권한을 가진 상태로 생성(d)하도록 되어 있다고 한다. 하지만 무슨 이유에서인지 내게선 해당 디렉터리가 생성되고 있질 않았다. 조금 더 찾아보니 아래 경로에 같은 명령어를 가진 설정파일을 추가한 뒤, MySQL을 초기화하면 디렉터리가 제대로 생성된다는 의견을 참고하여 작업해보았다.

 

<추가할 파일 경로>
$ vi /etc/tmpfiles.d/mysqld.conf
$ vi /etc/tmpfiles.d/mysql.conf
$ vi /usr/lib/tmpfiles.d/mysql.conf
$ vi /usr/lib/tmpfiles.d/mysqld.conf

<파일 내용>
d /var/run/mysqld 0755 mysql mysql -

<초기화>
$ cd /usr/lib/
$ mv mysql mysqll
$ mysql --initialize

 

  vi  편집기로 해당 경로에 .conf 파일을 생성하여 내용을 기재하고 저장했다. 총 네 군대에 설정파일을 저장한 뒤 MySQL을 초기화했다. 초기화 하는 과정에서 디렉터리를 변경한 뒤 mysql 디렉터리명을 mysqll로 바꾼 이유는, 그렇지 않고 초기화를 진행할 경우 file or directory already existed 에러가 출력되기 때문이다. 

 

 MySQL의 초기화가 완료되었다면 모든 설정파일 및 디렉터리의 권한이 초기 설정 값 그대로 재설정 되었을 것이므로, 다시 한 번 MySQL 관련된 모든 디렉터리의 권한을 조정해줘야만 한다. 아래의 명령어를 차례대로 실행하자.

 

chmod 755 -R /usr/lib/mysql

chown mysql:mysql -R /usr/lib/mysql

systemctl start mysqld

 

 이렇게까지 했음에도 불구하고 여전히 (111) 에러가 발생하고 있다. 이틀에 가까운 시간을 소요해서 모든 검색 결과를 전부 뒤져본 뒤 실행해봤음에도 불구하고 문제가 해결되지 않았다. 해당 에러의 문제는 MySQL 실행 시 /var/run/mysqld 디렉터리가 존재하지 않기에 발생하는 것이지만, 왜 해당 디렉터리를 생성하지 못하고 있는지는 밝히지 못했다 (아마도 WSL 문제일 듯 싶다).

 

 다만 조금 다른 방법으로 해당 문제를 해결해보기로 했다. crontab을 이용해서 윈도우가 부팅될 때 마다 해당 디렉터리를 생성해주는 방법으로, 근본적인 원인 해결은 아니지만 MySQL 실행을 위해 /var/run/mysqld 디렉터리 생성을 자동화 해주는 로직이다.

 

$ crontab -e
@reboot mkdir /var/run/mysqld && chown mysql:mysql /var/run/mysqld
@reboot systemctl restart nginx
@reboot systemctl restart php-fpm
@reboot systemctl restart mysqld

 

 crontab이란 window의 스케줄러와 같은 기능으로, crontab 서비스가 시작 & 실행 중일 때, 기재된 명령어를 설정된 시간 및 옵션에 따라 수행하는 역할을 한다.  -e  는 새롭게 명령어를 추가한다는 의미이며, @reboot 옵션은 crontab 서비스가 boot & reboot 할 때 마다 해당 명령을 수행하겠다는 의미이다. 추가적으로 LEMP 환경을 동시에 서비스 할 수 있도록 명령어를 기재했다.

 

systemctl start crond

 

 이제 해당 명령어를 실행할 때 마다 /var/run/mysqld 디렉터리가 생성됨은 물론이고, LEMP환경이 수행됨과 동시에 mysql 또한 오류 없이 정상적으로 실행되는 것을 확인했다. MySQL 서비스가 종료되거나 WSL 환경이 종료되거나 PC가 OFF 될 때 마다 myslqd 디렉터리가 사라지는 것도 확인이 되었고, mysqld 디렉터리가 존재할 떄 crontab 서비스가 시작되어도 별도의 오류 없이 정상적으로 모든 서비스가 실행 되는 것도 확인되었다. 참고로 메모장에  wsl systemctl start crond  를 기재한 뒤 .bat 파일로 저장하고, 이를 C:\Users\자신의PC사용자명\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup 

 

뭔가 이런 느낌...

 사실 이것도 방법 중 하나라고 생각한다. 꼭 정답이 하나만 있어서 그걸 따라만 가야 하는 건 아니니까. 다만 이게 나중에 가서 어떤 사이드 이펙트를 발생시킬지 모르고, 배포 환경에서 어떤 장애 요소를 가지고 있을 지 지금의 나는 모르겠지만, 그 때의 문제는 그 때 가서 해결해보기로 하자. 당장은 이렇게라도 해결했으니 다행이라고 여기고 있어야겠다.

 

 

 

 

댓글