Ubuntu는 안정적인 배포판이지만 apt update/apt install 도중 여러 이유로 실패하는 경우가 잦다. 원인은 크게 세 가지로 나뉜다 — 다른 프로세스가 dpkg 락을 잡고 있는 경우, 이전 설치 작업이 중간에 끊겨 dpkg 상태가 꼬인 경우, 서드파티 저장소의 GPG 서명 키가 없는 경우다. 이 글에서는 이 세 가지 오류를 실제로 재현하고 그 해결 과정을 정리한다.
dpkg 락 대기 (Could not get lock)
다른 apt/dpkg 프로세스나 unattended-upgrades가 실행 중이면 /var/lib/dpkg/lock-frontend를 다른 프로세스가 잡고 있어 아래처럼 대기 메시지가 뜬다. Ubuntu 24.04의 최신 apt는 락이 풀릴 때까지 자동으로 재시도하며, 락을 쥔 프로세스가 끝나면 이어서 정상 진행된다.
$ sudo apt install -y cowsay
Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 8156 (python3)...
Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 8156 (python3)...
...
Reading package lists...
Setting up cowsay (3.03+dfsg2-8) ...
기다려도 끝나지 않는다면 락을 쥔 프로세스가 실제로 살아 있는지부터 확인한다.
sudo fuser -v /var/lib/dpkg/lock-frontend
ps -p <PID>
해당 PID가 이미 죽어 있는데도 메시지가 계속되면(비정상 종료로 락 파일만 남은 경우) 그때만 락 파일을 지운다. 프로세스가 살아있는데 강제로 락 파일을 지우면 dpkg 데이터베이스가 손상될 수 있으므로 프로세스 생존 여부를 반드시 먼저 확인해야 한다.
sudo rm /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock
sudo dpkg --configure -a
dpkg 중단 (dpkg was interrupted)
설치 도중 강제 종료나 전원 문제로 dpkg가 중단되면 패키지가 half-configured 상태로 남는다. 실제로 postinst 스크립트 실행 중 dpkg 프로세스를 강제 종료해서 재현하면 이후 apt install이 곧바로 아래 오류로 실패한다.
$ dpkg -l dummy-slow-test
||/ Name Version Architecture Description
+++-===============-=======-============-===================
iF dummy-slow-test 1.0 all dummy package ...
$ sudo apt install -y tree
E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.
iF는 “Install, Failed-config” 상태를 뜻한다. 안내 그대로 dpkg --configure -a를 실행하면 중단됐던 postinst가 다시 실행되며 정상 상태(ii)로 복구된다.
$ sudo dpkg --configure -a
Setting up dummy-slow-test (1.0) ...
$ dpkg -l dummy-slow-test
||/ Name Version Architecture Description
+++-===============-=======-============-===================
ii dummy-slow-test 1.0 all dummy package ...
GPG 서명 키 누락 (NO_PUBKEY)
서드파티 저장소를 signed-by 없이 sources.list.d에 추가하면 그 저장소의 GPG 공개키가 로컬에 없어 아래처럼 실패한다.
$ cat /etc/apt/sources.list.d/docker-test.list
deb https://download.docker.com/linux/ubuntu noble stable
$ sudo apt update
Err:4 https://download.docker.com/linux/ubuntu noble InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 7EA0A9C3F273FCD8
E: The repository 'https://download.docker.com/linux/ubuntu noble InRelease' is not signed.
apt-key는 deprecated이므로, 키를 /etc/apt/keyrings/에 내려받아 저장소 줄의 signed-by로 직접 지정하는 방식이 현재 권장되는 방법이다.
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo "deb [signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu noble stable" | sudo tee /etc/apt/sources.list.d/docker-test.list
$ sudo apt update
Get:4 https://download.docker.com/linux/ubuntu noble InRelease [48.5 kB]
Get:5 https://download.docker.com/linux/ubuntu noble/stable amd64 Packages [61.6 kB]
Fetched 110 kB in 1s (190 kB/s)
Reading package lists... Done
주의사항
- 락 파일을 지우기 전엔 반드시
fuser/ps로 해당 프로세스가 죽었는지 확인한다. 살아있는 프로세스의 락을 강제로 없애면 두 프로세스가 동시에 dpkg 데이터베이스를 건드려 실제로 데이터베이스가 손상될 수 있다. dpkg --configure -a로도 해결되지 않으면 문제가 된 패키지만sudo apt purge <package>후 재설치하는 편이 안전하다.apt-key add는 Ubuntu 22.04부터 deprecated 경고가 뜨고 향후 제거될 예정이므로, 새 저장소를 추가할 땐 처음부터signed-by+/etc/apt/keyrings/방식을 쓴다.
마무리
락 대기, dpkg 중단, GPG 키 누락 세 가지 모두 메시지 자체에 원인과 다음 명령이 그대로 나와 있는 경우가 많아, 에러 문구를 끝까지 읽고 그대로 따라가면 대부분 해결된다. 락/데이터베이스 문제는 무엇보다 강제로 파일을 지우기 전에 프로세스 생존 여부부터 확인하는 습관이 중요하다.