0

On Debian11/KDE when trying to upgrade packages (and earlier sudo apt-get update as well) it displays the following error message:

Cannot get the exclusive lock on the package backend.
Please close any other legacy packaging tools that may be open.

E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process {id} (unattended-upgr)
W: 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?

In the process manager (KSysguard) the process-tree is like this:

apt.systemd.dai->apt.systemd.dai->unattended-upgr->unattended-upgr->unattended-upgr

When I try to "End Process" in KSysGuard it just gets restarted (and that wouldn't be the solution anyway). The process finishes after a while but there are still security updates that haven't been implemented so I'm not sure what it does / how it's useful.

I also had this problem after a dist-upgrade.

How to abort unattended-upgrades or configure it so that it gets aborted automatically once apt-get is used to upgrade? I think it should be as easy as possible (by default) to update packages and something blocking the update could be a problem for people who just started using GNU/Linux or aren't interested in spending time to solve this problem of updating suddenly not working for unknown reasons. Some people recommend to manually (via commands) temporarily stop (even requiring a reboot) or permanently remove the unattended-upgr package.

Concerning permanently removing unattended-upgr I think that upgrading packages in the background would be useful but is unattended-upgr actually doing so?

In any case if this isn't a bug or a problem of Debian's default configuration of it, it currently seems to decrease user-friendliness / convenience / UX.

Improve this question

1 Answer 1

Reset to default
1

It is possible to execute the unattended-upgrades during the shutting down process, allowing you to execute apt anytime instead of aborting apt process.

Enable this option in your /etc/apt/apt.conf.d/50unattended-upgrades

Unattended-Upgrade::InstallOnShutdown "true";

cat /etc/apt/apt.conf.d/50unattended-upgrades:

// Install all updates when the machine is shutting down
// instead of doing it in the background while the machine is running.
// This will (obviously) make shutdown slower.
// Unattended-upgrades increases logind's InhibitDelayMaxSec to 30s.
// This allows more time for unattended-upgrades to shut down gracefully
// or even install a few packages in InstallOnShutdown mode, but is still a
// big step back from the 30 minutes allowed for InstallOnShutdown previously.
// Users enabling InstallOnShutdown mode are advised to increase
// InhibitDelayMaxSec even further, possibly to 30 minutes.
//Unattended-Upgrade::InstallOnShutdown "false";
Improve this answer
2
  • Helpful solution but kind of a workaround...this doesn't work if one doesn't shutdown often (which is also a reason why this wouldn't be viable for a per-default setting). (And I'm still not sure what unattended-upgr does if it's not installing the security upgrades which seems to be the case.) I just thought what if apt quit unattended-upgr whenever it is run (directly or via a tool like Apper)...I guess I'll ask about that in an issue in the apt source code repo.
    – mYnDstrEAm
    Oct 10, 2021 at 20:22
  • In addition to getting gracefully quit when the user tries to manually update packages (and showing a better error-message), it could be prevented from running during the hours after which one was notified of new packages (due to running apt-get update, or trying to dist-upgrade or due to a apt-get update cronjob etc) via a per-default setting because that's when it's most likely that the user will make use of the upgrading.
    – mYnDstrEAm
    Oct 11, 2021 at 8:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .