The Could not get lock /var/lib/dpkg/lock-frontend error means another process is using apt or dpkg, and on a new cloud VM that is often Ubuntu's automatic updates, so wait for it to finish and do not delete the lock file.
E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1234 (unattended-upgr)
N: Be aware that removing the lock file is not a solution and may break your system.
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
That is what apt-get prints. The apt command shows the first message as a progress line and keeps waiting:
Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1234 (unattended-upgr)... 12s
The messages come from apt's source, fileutl.cc and debsystem.cc, checked 12 November 2026, and the same wording is in the 2.4, 2.7 and 2.8 releases. The number is the process ID. The name is read from /proc/PID/status, where the proc manual says names are cut at 15 characters, so unattended-upgr is the start of unattended-upgrade.
Why apt could not get lock /var/lib/dpkg/lock-frontend on a new VM
Ubuntu's automatic updates documentation says security updates are applied without user interaction by the unattended-upgrades package, which is installed by default and runs once a day. Two systemd timers, apt-daily.timer and apt-daily-upgrade.timer, trigger the package list update and the upgrade at a scheduled time with a random delay, and if the machine was off when a timer was due, the run can start soon after boot. The documentation describes this case: "VM images that are only started for some quick action", which is "delayed or even blocked by the unattended upgrades".
cloud-init can also run apt during boot, but its documentation says package_update and package_upgrade default to false, so it only does when the VM's cloud-init configuration asks. DeployGPU does not document what each provider's boot configuration runs, so look at what holds the lock instead of guessing.
Waiting for cache lock is not an error
The apt source sets Dpkg::Lock::Timeout for the apt command to -1 when its input is a terminal and to 120 otherwise, and a negative value waits without limit. apt-get has no such default and fails at once. So an interactive sudo apt install waits by itself, and the same command without a terminal on its input, such as in a cron job, gives up after 120 seconds. The same message can name /var/lib/apt/lists/lock or /var/cache/apt/archives/lock, which apt takes while it updates its package lists or downloads packages, and the cure is the same.
See which process holds the lock
ps -o pid,user,etime,args -p 1234
sudo fuser -v /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/lib/apt/lists/lock /var/cache/apt/archives/lock
systemctl status apt-daily.service apt-daily-upgrade.service
sudo tail -n 20 /var/log/unattended-upgrades/unattended-upgrades.log
Use the process ID from the message. The ps manual defines etime as the time since the process started, and the fuser manual says -v lists processes in a ps-like style and that it needs privileges to see other users' processes. sudo lsof /var/lib/dpkg/lock-frontend lists the processes that have that file open, per the lsof manual. The daily upgrade is the apt-daily-upgrade.service unit, which runs apt.systemd.daily, and the systemd manual says a one-shot service reads activating while its process runs. The unit named unattended-upgrades is a different thing: its unit file calls it Unattended Upgrades Shutdown. The project's README says every operation is logged under /var/log/unattended-upgrades/.
Wait for it safely
fuser exits with 0 while at least one process uses a file, so this loop runs until all four lock files are free:
while sudo fuser -s /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/lib/apt/lists/lock /var/cache/apt/archives/lock; do sleep 5; done
sudo apt-get install -y tmux
apt can also wait for you. The apt-get manual defines -o as setting a configuration option, and a positive DPkg::Lock::Timeout makes apt wait that many seconds before it fails with the Unable to acquire the dpkg frontend lock error. The man pages do not describe this option, but the source reads it and the /usr/share/doc/apt/examples/configure-index example file that the apt.conf manual points to lists it as dpkg::lock::timeout:
sudo apt-get -o DPkg::Lock::Timeout=300 install -y tmux
If cloud-init is the holder, cloud-init status --wait blocks until it completes, per its CLI reference. On a GPU VM, an automatic upgrade that replaces driver files can leave the driver and library mismatch, and the NVIDIA drivers guide installs with apt too, so wait for the lock before you start it.
Why deleting the lock files is dangerous
The FAQ's answer is to let the other process finish, and for a frozen one to run sudo fuser -vki -TERM /var/lib/dpkg/lock /var/lib/dpkg/lock-frontend, which asks before each kill, followed by sudo dpkg --configure --pending. I would only go there when the log has stopped moving for a long time. If nothing on the VM is worth keeping, stopping it and launching a new one is cleaner, and the unused seconds of the current hour go back to your balance. I do not reboot to clear a lock, because it ends the holder at an arbitrary point in an upgrade, and the reboot rules in the NVML page apply to any DeployGPU VM.
When dpkg was interrupted
E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.
The source takes both locks before it checks the dpkg journal in /var/lib/dpkg/updates, so this error means nobody holds the lock now and an earlier run was cut off. The dpkg manual says --configure -a configures all packages that are unpacked but not configured. Run it, then repeat your command. If the earlier run stopped because the disk was full, No space left on device comes first. An error that ends in are you root? instead of is another process using it? usually means you ran apt without sudo.
Turn automatic upgrades off on a short-lived VM
Ubuntu's documentation turns them off by setting both options in /etc/apt/apt.conf.d/20auto-upgrades to 0, and the project README gives sudo dpkg-reconfigure -plow unattended-upgrades as the command-line route:
APT::Periodic::Update-Package-Lists "0";
APT::Periodic::Unattended-Upgrade "0";
Neither stops a run that has already started. The documentation's section on systems that get recreated says the security exposure is still there and only the update mechanism differs, so until a new deployment replaces the machine, outdated software might still be running. It also says that from Ubuntu 24.04 needrestart restarts the affected services after an upgrade by default. On a VM that I plan to stop within hours I would turn upgrades off and accept that. On one that stays up for weeks I would leave them on and wait.
When to contact support
Contact support if the holder is neither unattended-upgrades nor cloud-init, never ends, or sudo dpkg --configure -a fails. Email support@deploygpu.ai with the ps output, the end of the unattended-upgrades log, the provider and the deployment ID. The contact page is the other way in, and the first five minutes guide lists the checks for a new VM.
Frequently asked questions
How long does unattended-upgrades hold the lock?
Ubuntu's documentation gives no duration. It depends on what has to be upgraded, so watch the log in /var/log/unattended-upgrades and wait until the process ends.
Is it safe to delete /var/lib/dpkg/lock-frontend?
No. The lock belongs to a process and not to the file, and apt itself warns that removing the lock file may break your system.
What does Waiting for cache lock mean?
The apt command found the lock held and is waiting for it. With a terminal on its input it waits without limit, and without one it waits 120 seconds. The apt-get command does not wait by default.
Can I disable unattended-upgrades?
Yes, for future runs, by setting the two APT::Periodic options in 20auto-upgrades to 0. It does not stop a run in progress, and security updates then wait for you.
What does dpkg was interrupted mean?
An earlier apt or dpkg run was cut off before it finished. Run sudo dpkg --configure -a, then repeat your apt command.
Why does the process name say unattended-upgr?
Linux cuts a process name at 15 characters, so unattended-upgrade appears as unattended-upgr in the message.