최신 리눅스 배포판을 사용하고 있다면 시스템을 종료할 때 "A stop job is running"이라는 메시지를 본 적이 있을 것입니다. 이 메시지가 나타나면 종료 과정이 최대 90초까지 지연될 수 있습니다. 이번 글에서는 이 메시지가 왜 나타나는지, 그리고 어떻게 개선할 수 있는지 자세히 알아보겠습니다.
버그가 아닌 안전장치입니다
가장 먼저 알아야 할 사실은 "A stop job is running" 메시지는 시스템에 내장된 안전 기능이지 버그가 아니라는 점입니다.
Ubuntu, Fedora, Arch 같은 최신 리눅스 배포판은 Systemd를 사용해 부팅과 종료 과정을 관리합니다. 종료 버튼을 클릭하면 Systemd가 전원 코드를 뽑듯 강제로 끄는 것이 아니라, 실행 중인 모든 서비스와 애플리케이션에 SIGTERM이라는 종료 신호를 먼저 보냅니다. 대부분의 애플리케이션은 이 신호를 받으면 데이터를 저장하고 열려 있는 파일을 닫은 뒤 안전하게 종료됩니다.
하지만 일부 서비스는 작업을 마치는 데 더 많은 시간이 필요하거나 이 신호를 무시하는 경우가 있습니다. 바로 그때 경고 메시지가 표시되는 것입니다. 이러한 지연은 주로 네트워크 관리자, 컨테이너, 사용자 세션, 네트워크 마운트 드라이브처럼 연결을 닫거나 데이터를 안전하게 저장하는 데 추가 시간이 필요한 서비스 때문에 발생합니다.
많은 리눅스 사용자는 이 메시지를 보고 뭔가 고장 났다고 생각하고 해결책을 찾곤 합니다. 하지만 실제로는 Systemd 개발자들이 의도적으로 설계한 동작입니다. 즉, 이 대기 시간(보통 90초)은 Systemd가 서비스들에게 대기 중인 작업을 마칠 수 있도록 허용하는 시간입니다. 설정된 제한 시간 내에 서비스가 작업을 끝내지 못하면 Systemd는 SIGKILL로 강제 종료한 뒤 종료 프로세스를 계속 진행합니다.
이런 우아한(graceful) 종료 덕분에 많은 애플리케이션이 파일 닫기, 데이터베이스 트랜잭션 완료, 파일시스템 깔끔하게 언마운트 같은 마무리 작업을 안전하게 처리할 수 있습니다. 물론 대기 시간을 줄여 종료 속도를 높일 수도 있지만, 그럴 경우 최근의 쓰기 작업이나 트랜잭션이 유실되거나, 데이터베이스·저널 파일이 손상되거나, 마운트된 드라이브가 불안정한 상태로 남을 위험이 커집니다.
기본 타임아웃 줄이는 방법
90초라는 기본 대기 시간은 대부분의 서비스가 정리 작업을 마칠 충분한 시간을 확보해 주기 때문에, 특히 구형 하드웨어를 사용하는 환경에서는 합리적인 균형점입니다. 하지만 최신 노트북이나 데스크톱 사용자에게는 90초가 지나치게 길게 느껴질 수 있습니다.
이유가 무엇이든, 시스템 설정 파일을 수정해 타임아웃을 낮추고 Systemd에게 미완료 서비스에 일정 시간만 허용하도록 지시할 수 있습니다.
먼저 터미널을 열고 선호하는 텍스트 편집기로 시스템 설정 파일을 엽니다:
sudo nano /etc/systemd/system.conf
다음으로 타임아웃 변수를 찾습니다. 화면에는 시스템의 전역 설정이 담긴 많은 텍스트가 표시되는데, #DefaultTimeoutStopSec=90s와 비슷한 줄을 찾으세요. 줄 맨 앞의 해시(#) 기호는 해당 설정이 주석 처리되어 비활성화 상태라는 의미이며, 현재 시스템은 내부 기본값인 90초를 사용하고 있습니다.
값을 변경하려면 먼저 해시 기호를 제거해 줄을 활성화한 뒤, 90초를 원하는 더 짧은 시간으로 수정합니다.
주의: 이 값을 0으로 설정하면 안 됩니다. 0은 무한 대기를 의미하므로 시스템이 프로세스가 멈출 때까지 영원히 기다리게 됩니다. 우리가 원하는 것과 정반대의 결과입니다. 많은 사용자에게 20~30초 정도의 중간값이 현실적인 절충안입니다.
편집이 끝나면 저장하고 편집기를 종료합니다. 변경 사항을 적용하려면 재부팅이 필요합니다. 문제가 종료 과정에서 발생하기 때문에 마지막으로 한 번 더 긴 대기 시간을 겪을 수 있으며, 다음 부팅부터는 새로운 제한 시간이 적용됩니다.
참고: 경우에 따라 #DefaultDeviceTimeoutSec=90s 항목도 함께 활성화해야 적용될 수 있습니다.
타임아웃이 근본 문제를 나타낼 수 있는 경우
대부분의 경우 종료 작업 타임아웃은 정상적인 동작입니다. 하지만 동일한 서비스가 반복적으로 종료를 지연시킨다면 근본적인 문제를 의심해볼 필요가 있습니다. 네트워크 마운트에 접근할 수 없게 되었거나, 데몬이 잘못 구성되었거나, 서비스가 종료 신호에 제대로 응답하지 않는 상황일 수 있습니다.
종료에 몇 분씩 걸리거나 매번 같은 서비스가 타임아웃된다면 조사해볼 가치가 있습니다. 가끔 발생하는 지연은 대개 무해하지만, 지속적으로 발생한다면 시스템에 주의가 필요하다는 신호입니다.
느린 종료 후 재부팅했다면 로그를 확인해 지연의 원인이 되는 서비스를 파악할 수 있습니다:
journalctl -b -1 -e
이 명령은 이전 부팅 세션의 로그를 불러온 뒤 마지막 지점으로 이동합니다. 위로 스크롤하면서 경고 메시지, 타임아웃 기록, 강제 종료된 서비스를 찾아볼 수 있습니다.
또한 경고 수준의 메시지만 필터링해 범위를 좁힐 수도 있습니다:
journalctl -b -1 -p warning
Systemd 분석 명령어를 활용하는 것도 좋은 방법입니다:
systemd-analyze blame이 명령은 부팅 시간에 초점을 맞추지만, 시작이 느린 서비스는 종료 시에도 비슷한 경향을 보이는 경우가 많습니다. 종료 작업 메시지를 자주 유발하는 대표적인 서비스는 다음과 같습니다:
- 네트워크 서비스
- NFS, SMB 같은 원격 파일시스템
- 데이터베이스 서버
- 컨테이너 및 가상 머신 관리 도구
- 외장 드라이브 및 automount 유닛
특히 네트워크 기반 마운트는 연결이 불안정하거나 이미 사용할 수 없는 상태일 때 지연이 잦습니다. 종료 타임아웃을 줄이면 종료가 빨라진 것처럼 느껴지지만 근본적인 문제를 해결해 주지는 못합니다. 특정 서비스가 지속적으로 종료를 지연시킨다면, 근본 원인을 해결하는 것이 장기적으로 훨씬 더 나은 결과를 가져옵니다.
마무리
리눅스는 고집 센 서비스가 종료될 때까지 얼마나 기다릴지까지 포함해 시스템에 대한 높은 수준의 제어권을 사용자에게 제공합니다. 여기에 더해 백그라운드 애플리케이션을 관리하고 불필요한 서비스를 비활성화하면 종료 시간과 부팅 시간을 모두 크게 개선할 수 있습니다.