TROUBLESHOOTING LOG

리눅스 문제 해결 기록

직접 겪었던 문제를 그냥 넘기지 않고, 원인을 찾은 과정과 해결 방법을 다시 꺼내 볼 수 있도록 정리했습니다.

6 RECORDS

RECORD 01

집에서 Xshell 접속을 하려고 했지만 계속 접속 실패함

SSH · hosts.allow · 접속 로그

원인

ESXi에 접속하여 터미널에 w를 입력한 후 확인하니 여러 번의 공인 IP 접속 시도 기록을 발견했다. 아래 첫 번째 사진은 문제 해결 후에 찍은 예시 사진이라 원인의 상황과는 조금 다르다.

해결

/etc/hosts.allow를 확인하고 sshd : xxx.xxx.xx.xxx 형식으로 내 공인 IP를 추가했다.
/etc/hosts.deny에서 ALL : ALL인 것을 확인했다.
sudo service ssh restart를 입력하여 설정을 메모리에 갱신했다.
sudo journalctl -u ssh -f 또는 sudo tail -f /var/log/auth.log로 로그를 모니터링하며 상황을 체크했다.
Xshell로 다시 접속을 시도했다.

sudo service ssh restart
sudo journalctl -u ssh -f
# 또는
sudo tail -f /var/log/auth.log

사진을 누르면 원본 크기로 확인할 수 있습니다.

결과

로그를 보면서 Xshell 접속을 다시 시도했고 정상적으로 로그인되는 것을 확인했다.

RECORD 02

이벤트 스케줄러에 등록한 backup.sh가 정상 작동하지 않은 문제

Linux 권한 · 백업 경로 · Shell Script

원인

백업 위치가 /home 디렉터리가 아닌 root 권한 폴더에 있어서 일반 사용자 권한으로 실행하지 못한 것이었다.

해결 방법 1 · 폴더 소유권과 권한 변경

sudo chown -R master:master /backup
sudo chmod 775 /backup

해결 방법 2 · 스크립트의 백업 경로 수정

BACKUP_DIR="$HOME/backup"

mkdir -p "$BACKUP_DIR"

정리

사용자가 실제로 쓸 수 있는 위치를 백업 경로로 사용하거나, 필요한 폴더의 소유권과 권한을 정확하게 맞춰야 했다.

RECORD 03

192.168.0.18에 SSH로 접속할 때 90~120초 이상 지연됨

SSH · systemd · fstab · LVM

원인

/etc/fstab에 등록한 LVM 이름이 lv_storae로 잘못 적혀 있었다. 실제 Logical Volume 이름은 lv_storage였고, 존재하지 않는 장치를 기다리느라 SSH 로그인 과정이 지연되고 있었다.

문제 탐색 과정

Xshell에서도 같은 증상이 발생하여 VSCode만의 문제는 제외했다.

tail -f /var/log/auth.log에서 Accepted password를 확인하여 SSH 인증 자체는 정상이라고 판단했다.

/etc/pam.d/sshd와 /etc/pam.d/common-session을 확인했지만 특이사항은 없었다.

journalctl -b -p err에서 Timed out waiting for device /dev/vg_data/lv_storae를 발견했다.

/etc/fstab과 sudo lvs 결과를 비교하여 LVM 이름 오타를 찾았다.

해결

/etc/fstab의 lv_storae를 lv_storage로 수정했다.
sudo mount -a로 마운트 오류가 없는지 확인했다.
sudo systemctl daemon-reload로 설정을 다시 불러왔다.
재부팅 후 SSH 접속 속도를 다시 확인했다.

sudo lvs
sudo mount -a
sudo systemctl daemon-reload

결과

fstab의 LVM 이름 오타를 수정한 뒤 SSH 접속 지연 문제가 해결되었다. 이 작업은 다음 `/home` LVM 문제로 이어졌다.

RECORD 04

빈 LVM이 기존 /home 위에 마운트된 문제와 sudo 권한 복구

LVM · rsync · /home · 사용자 권한

원인

fstab을 수정한 뒤 빈 LVM이 기존 /home 위에 마운트되면서 lost+found만 보이게 되었다. 기존 사용자 데이터가 삭제된 것이 아니라 마운트 아래에 가려진 상태였다.

복구 과정

root로 로그인한 뒤 umount /home을 실행했다.

기존 /home에서 master, st1, st2, st3 등 모든 사용자 폴더가 남아 있는 것을 확인했다.

lv_storage를 /mnt/newhome에 마운트했다.

rsync로 기존 /home 데이터를 새 LVM으로 복사하고 완료 여부를 확인했다.

mount -a와 findmnt로 /home이 vg_data-lv_storage에 정상 마운트된 것을 확인했다.

새로 발견한 문제 · master의 sudo 권한

id master로 확인하니 sudo 그룹이 없었다. root로 로그인하여 그룹을 다시 추가한 뒤 SSH를 재접속했다.

usermod -aG sudo master
id master
sudo whoami

최종 결과

기존 /home 복구, 데이터 이전, LVM 기반 /home 구성, sudo 권한 복구까지 모두 완료했다. 마지막으로 sudo whoami에서 root가 출력되는 것을 확인했다.

가장 중요한 점

LVM에 대해서 뭘 할 땐 무조건 모든 파일을 백업하고 실행할 것!

RECORD 05

192.168.0.30 서버 구축 후 외부 SSH 접속이 되지 않은 문제

Netplan · SSH · TCP Wrapper · NAT

서버 설정과 내부 점검

ESXi에서 Ubuntu Server를 설치하고 Netplan으로 고정 IP를 설정했다. 이후 SSH 서비스, 22번 포트, hosts.allow와 내부 접속을 차례대로 확인했다.

sudo netplan generate
sudo netplan apply
hostname -I
ip addr

sudo systemctl status ssh
sudo ss -tlnp | grep ssh
ldd /usr/sbin/sshd | grep wrap
ssh master@192.168.0.30
nc -zv 192.168.0.30 22

외부 포트 확인

Windows에서 외부 접속 주소의 포트를 확인했다. 22018은 열려 있었지만 22030은 연결되지 않았다.

Test-NetConnection jeonjucom.kr -Port 22018
Test-NetConnection jeonjucom.kr -Port 22030

22018 · OPEN22030 · CLOSED내부 22번 · OPEN

원인 분석

30번 서버의 Netplan, IP, SSH 서비스와 내부 SSH 접속은 모두 정상이었다. 외부에서 22030만 닫혀 있었기 때문에 서버 자체가 아니라 외부 NAT 또는 포트포워딩 설정 문제로 판단했다.

핵심 원인 한 줄 요약

192.168.0.30 서버는 정상이며, Xshell 접속 불가는 22030 → 192.168.0.30:22 포트포워딩이 되어 있지 않거나 다른 외부 포트를 사용하기 때문으로 확인되었다.

RECORD 06

sudo netplan try 실행 후 서버 네트워크가 멈춘 문제

2026-07-01 · Netplan · VMXNET3 · ESXi

문제

sudo netplan try 명령어를 실행한 후 SSH 연결이 끊기고 외부 통신이 되지 않았다. 터미널도 응답하지 않았고, 이후 서버에 네트워크 문제 알림이 계속 올라왔다.

임시 조치 사항

교수님께 보고했다.
서버를 재부팅했다.
재부팅 후 다시 정상 작동하는 것을 확인했다.

SSH 연결 종료 화면과 VMXNET3 TX Hang 로그입니다.

문제 탐색 및 해결 과정

netplan try 실행 후 SSH 연결 끊김, 외부 통신 불가, 터미널 응답 없음 증상을 확인했다.

dmesg를 분석하여 NETDEV WATCHDOG, tx hang, resetting, NIC Link is Up 로그가 반복되는 것을 확인했다.

ethtool -i ens160으로 VMXNET3 드라이버를 사용 중인 것을 확인했다.

네트워크 인터페이스 재초기화 과정에서 VMXNET3가 비정상 상태에 빠졌다는 가설을 세웠다.

ESXi에서 네트워크 어댑터를 VMXNET3에서 E1000E로 변경했다.

같은 sudo netplan try 테스트를 다시 수행했다.

SSH와 외부 통신이 정상적으로 유지되고 TX Hang도 발생하지 않는 것을 확인했다.

내 결론

VMXNET3 드라이버는 네트워크를 재구성하는 과정에서 문제가 발생하는 이슈가 있었다. 그래서 E1000E 같은 것으로 변경하면 문제가 발생하지 않았다.

최종 결론

이번 문제는 Netplan 설정 오류가 아니라 VMXNET3 가상 네트워크 드라이버 문제로 확인되었다. netplan try 실행 시 네트워크 인터페이스가 재초기화되는 과정에서 VMXNET3가 TX Hang, 즉 송신 큐가 멈춘 상태에 빠졌고 그 결과 SSH와 외부 통신이 모두 중단되었다.

본 실습 환경인 ESXi와 Ubuntu 24.04.4에서 VMXNET3를 E1000E로 변경한 후 같은 테스트를 수행하니 문제가 재현되지 않았다.

netplan try란?

sudo netplan try는 네트워크 설정을 임시로 적용하는 명령어다. 가장 큰 목적은 SSH에서 네트워크 설정을 변경하다 접속이 끊겨도, 사용자가 제한 시간 안에 확인하지 않으면 이전 설정으로 자동 복구하기 위한 것이다.

명령어	특징
`netplan generate`	YAML을 읽어 설정 파일만 생성하며 네트워크는 변경하지 않는다.
`netplan try`	설정을 임시 적용한 뒤 사용자 확인을 기다린다.
`netplan apply`	설정을 즉시 적용하며 자동 복구 확인 과정이 없다.

기억할 점

netplan try 자체는 원격 접속을 잃는 것을 방지하기 위한 안전장치다. 이번에는 그 재적용 과정에서 사용 중이던 VMXNET3가 비정상 상태에 빠진 것이 문제였다.