기술자료

적용 환경

주로 발생하는 오류 형태

apt update, apt upgrade, apt install 또는 apt-get을 실행했을 때 다음과 같은 잠금 오류가 나타날 수 있습니다.

E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?

APT와 dpkg는 동시에 여러 패키지 작업이 데이터베이스를 변경하지 못하도록 잠금을 사용합니다. 따라서 이 메시지가 보인다고 해서 파일이 손상된 것은 아니며, 다른 패키지 관리 작업이 정상적으로 실행 중인 경우가 많습니다.

1. 가장 먼저 잠금을 보유한 프로세스 확인

오류가 발생하면 잠금 파일을 건드리기 전에 현재 실행 중인 패키지 관련 프로세스를 확인합니다.

ps -ef | grep -E '[a]pt|[d]pkg|[u]nattended'

출력에 apt, apt-get, dpkg, unattended-upgrade가 보이면 해당 프로세스가 실제로 패키지 작업을 수행 중인지 확인합니다.

fuser를 사용할 수 있는 환경에서는 주요 잠금 파일을 어떤 프로세스가 열고 있는지 직접 확인할 수 있습니다.

sudo fuser -v \
  /var/lib/dpkg/lock-frontend \
  /var/lib/dpkg/lock \
  /var/cache/apt/archives/lock \
  /var/lib/apt/lists/lock

오류 메시지에 잠금을 보유한 PID가 표시되었다면 해당 PID의 실행 시간과 상태를 확인합니다. 아래의 1234는 실제 오류 메시지에 표시된 PID로 바꾸십시오.

ps -p 1234 -o pid,ppid,etime,stat,cmd

실행 시간이 짧고 apt, dpkg, unattended-upgrade 명령이 정상적으로 보인다면 강제 종료하지 말고 완료될 때까지 기다리는 것이 가장 안전합니다.

2. apt-daily와 자동 보안 업데이트 확인

Ubuntu Server에서는 자동 보안 업데이트가 활성화된 환경이 많습니다. Canonical 문서에 따르면 unattended-upgrades는 기본적으로 정기적으로 실행되며, 이 시간에 수동으로 APT를 실행하면 잠금 오류가 발생할 수 있습니다.

먼저 관련 서비스 상태를 확인합니다.

systemctl is-active apt-daily.service
systemctl is-active apt-daily-upgrade.service
systemctl status apt-daily.service apt-daily-upgrade.service --no-pager

다음 실행 예정 시간은 timer 상태에서 확인할 수 있습니다.

systemctl list-timers --all apt-daily.timer apt-daily-upgrade.timer

자동 업데이트가 실제로 무엇을 수행했는지는 저널과 unattended-upgrades 로그에서 확인합니다.

sudo journalctl -u apt-daily.service -u apt-daily-upgrade.service -b --no-pager
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log

패키지를 내려받거나 설치하는 기록이 계속 추가되고 있다면 정상적인 작업일 가능성이 높습니다. 이 경우 작업을 중지하거나 lock 파일을 삭제하지 말고 완료 후 APT 명령을 다시 실행하십시오.

3. 정상 작업과 비정상적으로 멈춘 작업 구분

정상적으로 실행 중인 경우

다른 관리자가 패키지를 설치 중이거나 자동 업데이트가 진행 중이라면 작업이 끝날 때까지 기다립니다. 잠금이 해제된 뒤 다음 명령으로 다시 시도합니다.

sudo apt update

패키지 설치나 업그레이드 자동화에서 잠금이 잠시 풀리기를 기다리도록 하려면 APT의 DPkg::Lock::Timeout 옵션을 사용할 수 있습니다. 다음 예시는 dpkg frontend 잠금을 최대 120초 기다린 뒤 설치를 진행합니다.

sudo apt -o DPkg::Lock::Timeout=120 install PACKAGE_NAME

PACKAGE_NAME은 실제 설치하려는 패키지명으로 변경합니다. 이 옵션은 잠금을 우회하는 기능이 아니라, 다른 dpkg 작업이 종료될 때까지 일정 시간 기다리는 기능입니다.

장시간 변화 없이 멈춘 것으로 의심되는 경우

장시간 동일한 PID가 유지된다고 해서 즉시 강제 종료해서는 안 됩니다. 먼저 해당 프로세스의 실행 시간, 상태, 자식 프로세스를 확인합니다.

ps -p 1234 -o pid,ppid,etime,stat,wchan:32,cmd
pgrep -a -P 1234

로그도 함께 확인합니다.

sudo tail -n 100 /var/log/apt/term.log
sudo tail -n 100 /var/log/dpkg.log

프로세스가 명백히 비정상 상태이고 더 이상 작업이 진행되지 않는다는 것을 확인했다면 먼저 일반 종료 신호를 보냅니다.

sudo kill -TERM 1234
sleep 5
ps -p 1234 -o pid,etime,stat,cmd

프로세스가 종료되었다면 바로 lock 파일을 삭제하지 말고 다음 절의 dpkg 복구 절차를 진행합니다.

4. 중단된 dpkg 상태 복구

APT 또는 dpkg 작업이 비정상 종료되었다면 먼저 잠금을 보유한 프로세스가 더 이상 없는지 다시 확인합니다.

ps -ef | grep -E '[a]pt|[d]pkg|[u]nattended'
sudo fuser -v /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock

활성 패키지 프로세스가 없다면 dpkg가 미완료 패키지를 보고하는지 확인합니다.

sudo dpkg --audit

이전 패키지 설정이 중단되었다면 다음 명령으로 미완료 configure 작업을 계속합니다. APT 소스 코드에서도 dpkg journal이 중단된 상태일 때 dpkg --configure -a 실행을 안내합니다.

sudo dpkg --configure -a

의존성 문제까지 남아 있다면 APT의 broken dependency 복구를 실행합니다.

sudo apt --fix-broken install

마지막으로 패키지 목록을 갱신합니다.

sudo apt update

각 명령이 오류 없이 종료되는지 확인합니다. dpkg --configure -a에서 특정 패키지의 post-install 스크립트 오류가 발생한다면 lock 문제가 아니라 해당 패키지의 설정 오류를 별도로 해결해야 합니다.

5. 해결 여부 확인

잠금 오류가 해결되었는지 다음 순서로 확인합니다.

1. 현재 다른 APT 또는 dpkg 프로세스가 없는지 확인합니다.
2. dpkg --audit에서 미완료 패키지가 남아 있지 않은지 확인합니다.
3. apt update가 lock 오류 없이 끝나는지 확인합니다.
4. 필요하면 실제 패키지 설치 또는 업그레이드를 다시 실행합니다.

sudo dpkg --audit
sudo apt update

최근 패키지 작업 이력을 확인하려면 다음 로그를 확인할 수 있습니다.

sudo tail -n 100 /var/log/apt/history.log
sudo tail -n 100 /var/log/dpkg.log

잠금 오류가 사라졌지만 저장소 오류, DNS 오류 또는 의존성 오류가 새로 표시된다면 해당 문제는 APT lock과 별개의 원인입니다.

상황별 원인과 해결 방법

클라우드 서버 첫 부팅 직후 발생하는 경우

클라우드 이미지에서는 첫 부팅 시 cloud-init이 패키지를 갱신하거나 설치하도록 설정되어 있을 수 있습니다. 이 경우 cloud-init 완료 여부를 확인합니다.

cloud-init status --wait

명령이 완료된 뒤 다시 sudo apt update를 실행해 잠금 오류가 사라졌는지 확인합니다. 시스템에 cloud-init이 설치되지 않은 경우에는 이 항목을 건너뛰면 됩니다.

재발 방지 방법

• 여러 관리자나 자동화 도구가 동시에 apt 또는 dpkg를 실행하지 않도록 작업 시간을 조정합니다.
• 서버 부팅 직후에는 apt-daily, unattended-upgrades, cloud-init이 끝났는지 확인한 뒤 수동 패키지 작업을 시작합니다.
• 자동화 스크립트에서는 즉시 실패시키기보다 DPkg::Lock::Timeout을 사용해 짧은 시간 대기하도록 구성할 수 있습니다.
• 패키지 설치 중 SSH 세션을 강제로 종료하거나 서버를 재부팅하지 않습니다.
• 잠금 오류 해결을 목적으로 자동 보안 업데이트 전체를 비활성화하는 것은 권장하지 않습니다.
• /var/log/apt/, /var/log/dpkg.log, /var/log/unattended-upgrades/를 이용해 장시간 패키지 작업의 원인을 추적합니다.

관련 지구 IDC 기술자료

• Ubuntu 20.04 시스템 모니터링 툴로 서버 점검 — 패키지 작업 외에 서버 자원이나 프로세스 상태를 추가로 확인할 때 참고할 수 있습니다.

공식 참고자료

자주 묻는 질문

lock-frontend 파일이 보이면 삭제해도 되나요?

권장하지 않습니다. 잠금 파일이 디스크에 존재하는 것과 실제로 프로세스가 잠금을 보유하고 있는 것은 다릅니다. fuser, ps, 오류 메시지의 PID를 이용해 실제 보유 프로세스를 먼저 확인해야 합니다.

unattended-upgrades 때문에 오류가 나면 서비스를 꺼야 하나요?

잠금 오류 해결만을 목적으로 자동 보안 업데이트를 비활성화하는 것은 권장하지 않습니다. 정상적인 업데이트라면 완료될 때까지 기다리고, 정기 유지보수 시간과 자동 업데이트 시간이 자주 충돌한다면 운영 정책에 맞게 실행 시간을 조정하는 편이 좋습니다.

서버를 재부팅하면 해결되나요?

실행 중인 패키지 작업을 재부팅으로 끊으면 dpkg가 미완료 상태로 남을 수 있으므로 우선 권장되는 방법이 아닙니다. 정상 프로세스인지 확인하고 기다린 뒤, 비정상 종료가 있었다면 dpkg --configure -a로 상태를 복구하십시오.

kill -9로 apt 프로세스를 종료해도 되나요?

가능하면 사용하지 마십시오. 특히 dpkg가 파일을 풀거나 패키지 설정 스크립트를 실행하는 중이라면 강제 종료로 미완료 상태가 생길 수 있습니다. 프로세스가 실제로 멈춘 것을 확인한 경우에도 먼저 SIGTERM으로 정상 종료를 시도해야 합니다.

dpkg --configure -a를 실행해도 오류가 계속되면 어떻게 하나요?

그 단계에서 표시되는 특정 패키지명과 오류 메시지를 확인해야 합니다. post-install 스크립트 실패, 디스크 용량 부족, 손상된 의존성, 저장소 문제 등은 APT 잠금과 다른 원인이므로 해당 오류를 기준으로 별도 진단해야 합니다.