Cannot obtain lock error on Discover

I am using plasma-discover and discover is opening. I am trying to install gimp or inkscape and it asks me password. When I put it correctly it shows task(100%) and stops popping up “cannot obtain lock”.

‘uname -a’ command returns Linux lubuntu 5.4.0-47-generic #51-Ubuntu SMP Fri Sep 4 19:50:52 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

The image I installed is downloaded from https://cdimage.ubuntu.com/lubuntu/releases/20.04.1/release/lubuntu-20.04.1-desktop-amd64.iso

Please help me out.

Does it happen all the time? Perhaps the update application is running and does not allow you to do both, Try launching the application from the console to see if it gives more information

The error message is normal, if you have two running processes which are dealing with packages.

What you can do:

  1. Close all your open Discover/Muon/Synaptic instances.
  2. Wait 15 minutes. Maybe there is an autoupdate running in the background.

If the problem still persists, than we have to find out, which process is blocking you.

1 Like

That error results from a second instance of an apt based install or update process while another is still running. This might be Synaptic, or Muon, for instance actively installing something while the user kicks off apt on the command line. Only one software install/update process can run at a time. Each tries to set the .lock, but can’t if the other already has control. Wait, or remove the .lock.

Let’s assume, that there is a very good reason for the .lock file. And let’s further assume that removing the .lock file is not the best idea of the century.
Based on these two assumptions, it is safe to say that your suggestion to remove the .lock file is completely misplaced, especially in a support forum, where we try to help and not to destroy.

1 Like

Not at all. There have been times when the .lock file has been left even after the apt/Synaptic/Muon session has ended. Yes, you should still make sure, but it’s not illegal, immoral, or fattening. Check into it, if it looks like the .lock file exists when it shouldn’t, delete the .lock and start the process again.

Sorry, I don’t see the part in your post, where you did check into it. I see only a post two weeks after the initial post with the general recommendation to delete the file. I don’t see any evidence, that this particular case is one of the very few edge cases, where it could help.

This is a public forum, and the post can be found also by others with the “same” problem. Your “advice” might affect not only one system, but hundreds and thousands.
And in this forum, we try to give support, not to discuss laws and/or morality.

Nor am I discussing laws or morality. I am giving a possible solution. The edge case being that all apt-driven update processes have completed, but the .lock file is not closed, as it normally should. Then, you are free to delete the .lock file and try the update again.

As a part of that edge case, if a GUI based software manager, such as Synaptic, is still active, even if it is not doing any actual updates, then it has the .lock file. Then you can exit Synaptic, and the .lock file SHOULD be deleted. If it is not, then you are free to do so.

You are also free to use your own intellect on this matter. I’m not telling what you MUST do, I am telling you what you MAY do.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.