1y ago

Unable to run apt update | Lock held by apt-get

I'm still a fairly new Linux-user (on Tuxedo OS), and I just ran into an issue that is new to me. If I try to update my system, either via command line or Discover, the apt update command fails. This is the output:

 undefined

    
E: Could not get lock /var/lib/apt/lists/lock. It is held by process 1635 (apt-get)
N: Be aware that removing the lock file is not a solution and may break your system.
E: Unable to lock directory /var/lib/apt/lists/

Process 1635 is apt-get update run by root, and persists through restart. I am tempted to try to kill it (kill 1635), but I'm not sure if anything could break from that, so I thought I'd try to ask for help first before I do something stupid.

EDIT:

I have managed to update my system by killing the process, which releases the lock, and then going on to do normal sudo apt update and sudo apt upgrade. For the sake of troubleshooting, I tried to add back my third-party repos one by one, and none of them caused any problem. However, when rebooting the same issue as described above happens again. Software updates is set to "Manually" in the System settings.

In addition, everytime I ran sudo apt upgrade, at the end some update related to initramfs fails. My disk is encrypted using cryptsetup, and as I’ve come to understand, I should be very careful doing anything related to initramfs when that is the case. Here is the output:

 undefined

    
Processing triggers for initramfs-tools (0.140ubuntu13.2) ...
update-initramfs: Generating /boot/initrd.img-6.2.0-10018-tuxedo
I: The initramfs will attempt to resume from /dev/dm-2
I: (/dev/mapper/system-swap)
I: Set the RESUME variable to override this.
zstd: error 25 : Write error : No space left on device (cannot write compressed block) 
E: mkinitramfs failure zstd -q -1 -T0 25
update-initramfs: failed for /boot/initrd.img-6.2.0-10018-tuxedo with 1.
dpkg: error processing package initramfs-tools (--configure):
 installed initramfs-tools package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)

EDIT 2:

The issue seems to have been narrowed down to a failure of Tuxedo's driver configuration service that runs at boot. It is this process that calls apt-get (and something I should've seen earlier...), and systemctl status reveals some errors:

 undefined

    
aug. 08 15:33:56 laptop systemd[1]: Starting Tomte-daemon, finishes tasks that could not be accomplished before...
aug. 08 15:34:06 laptop tuxedo-tomte[1393]: no network found!! some fixes might not be applied correctly
aug. 08 15:34:06 laptop tuxedo-tomte[1393]: systemctlCmd: systemd-run --on-active="30sec" tuxedo-tomte configure all >/dev/null 2>&amp;1

I really appreciate the help from everyone so far. It's a good experience asking for help here, and I've learned a lot from your answers. Makes being a Linux newbie a lot easier. So thank you :)

Since this seems to be a very specific issue related to Tuxedo's own services, I will contact their support to get their input on what to do next.

34 comments

My first guess is unattended-upgrades is running, especially if this is shortly after booting. As others have said, ps aux | grep apt will tell you what’s running. If it’s holding up all the time there might be something wrong with apt causing the update to hang.
- Yeah, it happens straight after boot, but it never resolves itself. And the process exists after reboot as well, so it seems that it starts running apt-get update and gets stuck / hangs.
  
  Definitely sounds like auto-update if it's respawning itself on every boot. The fact that it never exits is weird though; have you added any third party repos? What's in your apt sources.list file(s)?

I haven't used Tuxedo, but on apt-based distros it's pretty common for an auto-update daemon of some kind to run in the background on startup to either download updates, or at least download package metadata so some UI component can start nagging you to install the updates that are available.
If you wait a few minutes, the download should complete and you can do what you want. You can probably get away with killing it, especially if you use a gentle signal like HUP. I wouldn't risk it though... if you corrupt your package metadata or worse... and actual important package... it can be a significant hassle to clean up the mess. And the cost of waiting 30s-5m and trying again is so low it's hard to beat that as an approach.
If its happening a ton you can probably find and disable the auto-update thing but I don't know what it would be on Tuxedo.
- It persists even after several hours. Never happened before, and I've been using the system for about 6 months now. I posted the output from the process tree below, but I'm not sure if that makes anything any clearer. It's as if it is not receiving any data and just waiting for the servers to respond?

Check if the process is actually running
‘ps aux | grep 1635’
(You should see a line output)
More likely its not running and crashed without cleaning up the lock file, you might want to figure out why from logs and whatnot but its ok also to remove that file and try again
- (You should see a line output)
  Just a reminder that the line you see shouldn't be the grep line. You can use 'ps aux | grep 1635 | grep -v grep'
- It's showing up in the list with a bunch of sub-processes that looks like https-requests (I posted the output below). Which logs could I check to learn more about what's happened?
  When you say remove the file, do you mean the lock file?

killing the apt update shouldn't break anything since its not installing any packages it's just updating your repos. i would have just killed the pid 1635...also not sure if it would break something but i doubt it...did you dmesg to see what else info you might be able to find out?
- Would there not be a risk of corrupting some of the repo files and dependencies lists by just killing it?
  I have checked dmesg after your suggestion, but I did not see anything that tipped me off to what might be wrong. Is there anything in particular I should be looking for?

I would recommend trying out the process tree
Use ps auxf | less
And then / to search for the process. See what child processes are running from that aptget. I wouldn't expect much but that should give you an idea about the safety of killing it
- Here is the output from running that command:
  undefined
  
  root 1635 0.0 0.0 22208 8928 ? S aug.06 0:00 \_ apt-get update _apt 1654 0.0 0.0 27528 9600 ? S aug.06 0:00 \_ /usr/lib/apt/methods/https _apt 1655 0.0 0.0 27528 9600 ? S aug.06 0:00 \_ /usr/lib/apt/methods/https _apt 1656 0.0 0.0 27528 9600 ? S aug.06 0:00 \_ /usr/lib/apt/methods/https _apt 1657 0.0 0.0 27528 9760 ? S aug.06 0:00 \_ /usr/lib/apt/methods/https _apt 1658 0.0 0.0 27528 9760 ? S aug.06 0:00 \_ /usr/lib/apt/methods/https _apt 1659 0.0 0.0 27528 9760 ? S aug.06 0:00 \_ /usr/lib/apt/methods/https _apt 1660 0.0 0.0 27528 9760 ? S aug.06 0:00 \_ /usr/lib/apt/methods/https _apt 1661 0.0 0.0 27528 9600 ? S aug.06 0:00 \_ /usr/lib/apt/methods/https _apt 1662 0.0 0.0 20908 6880 ? S aug.06 0:00 \_ /usr/lib/apt/methods/mirror+file _apt 1663 0.0 0.0 27528 9760 ? S aug.06 0:00 \_ /usr/lib/apt/methods/https _apt 1664 0.0 0.0 27528 9920 ? S aug.06 0:00 \_ /usr/lib/apt/methods/https _apt 1667 0.0 0.0 27532 10080 ? S aug.06 0:00 \_ /usr/lib/apt/methods/https _apt 1669 0.0 0.0 20864 7680 ? S aug.06 0:00 \_ /usr/lib/apt/methods/file
  
  Nice, so here's your next step. Do a Google search and see what exactly that file is. Find out it's purpose and that'll give you an idea what's going on, which then allows you to determine if it's safe to kill or not.
  I already looked it up, so I want you to do the same and let me know what you find out and what you think they are being used for.

34 comments