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:

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.

  • toasteecup@lemmy.worldEnglish
    2·
    1 year ago

    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

    • cyberwolfie@lemmy.mlOP
      3·
      1 year ago

      Here is the output from running that command:

      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
      • toasteecup@lemmy.worldEnglish
        11·
        1 year ago

        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.

        • cyberwolfie@lemmy.mlOP
          1·
          1 year ago

          As far as I can tell, these are the methods apt uses to get information from the repositories that is listed within sources.list and within the sources.list.d directory. The number of subprocesses almost matches the number of sources there - in reality there are 14 listed, not 13 as is seen in the ps output. I can find one entry that starts with mirror+file, but otherwise there are 13 https entries. So that last line I am not sure what is doing.

          Anyways, it seems to me that it gets stuck somewhere updating the repositories list. Right now, I’m stuck with three questions:

          1. I’m still unsure as to whether it would be safe to kill the process, as I could imagine that having a corrupted depencies files could be really bad?
          2. Also, would killing the process automatically release the lock, or would I need to remove that myself after?
          3. Is there any reason to believe that this would even work, seeing as this happens everytime on boot. I imagine that if I kill the process, delete the lock and try to run sudo apt update I just end up the same place again.
          • toasteecup@lemmy.worldEnglish
            2·
            1 year ago

            So my theory on what’s going on is this.

            I suspect that this is an automatically running update to try to help keep your packages up to date, and I think it’s getting stuck on a source configured in your /etc/apt/sources.list I’m willing to bet it’s likely a source configured to pull from a “CD” which is used during installation and they forgot to disable that one.

            You should be able to stop it, it’ll still be locked but you’ll need find the lock file (I forgot where it’s configured) and just remove it with a simple rm, you’ll probably need to sudo the rm though.

            So my order of operations would be, kill the process, try to rerun the apt update and see if that tells you which repo it’s getting stuck on.