hi am having this issue when killing process ps aux | grep -i dpkg devops 12626 0.0 0.0 21532 1044 pts/0 S+ 06:31 0:00 grep --color=auto -i dpkg devops@devops-VirtualBox:~$ sudo kill -9 12626 kill: (12626): No such process devops@devops-VirtualBox:~$ sudo kill 12626 kill: (12626): No such process devops@devops-VirtualBox:~$ ps aux | grep -i dpkg devops 13970 0.0 0.0 21532 1048 pts/0 S+ 06:32 0:00 grep --color=auto -i dpkg devops@devops-VirtualBox:~$ sudo kill - 13970 kill: failed to parse argument: '-' devops@devops-VirtualBox:~$ sudo kill -9 13970 kill: (13970): No such process devops@devops-VirtualBox:~$
sudo apt-get install \ > apt-transport-https \ > ca-certificates \ > curl \ > software-properties-common E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable) E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
LinuxLinux SecurityLinux NetworkingLinux OS DevLinux Distributions
Last Comment
dfke
8/22/2022 - Mon
Alex [***Alex140181***]
You're trying to kill your very own session?! The one, you're doing the grep... Obviously, there is no other matching process you're looking for...
simon3270
The "dpkg" program isn't running. The only process that the "grep" finds is the grep itself (because you are looking for the string "dpkg", and that exact string appears on the "grep" command line so it matches).
By the time you get the next $ prompt, the grep command has finished, so the PID that you see in the output is no longer running.
You're actual problem is that a previous dpkg run (probably called from an "apt" command) terminated badly, and left the lock file. We are pretty sure that dpkg is no longer running, so just remove the file /var/lib/dpkg/lock-frontend (you will need to be root to do this), then you can run the apt command again.
If you want to avoid the confusion caused by outputting the "grep" command itself, you have a few options.One is to use the "pgrep" command, which specifically avoids reporting itself. Another is to pipe the output of your command through "| grep -v grep" - this works fine, until the command you are looking for is processing a file call, for example, planningreport.txt. A third is to modify the string you are looking for, so that the pattern that grep uses doesn't match the string in the command line - for example
ps aux | grep '[d]pkg'
This would still find the string "dpkg" in the "ps" output if the dpkg program was running, but the grep parameter has extra characters which don't match the string "dpkg" exactly so it won't find the grep command
Edit: Numerous typos - I did this on a computer rather than my phone to avoid typos - bad call!.
This should output the PID or PID's that keep it locked. Then sudo kill -9 on those and try again.
Cheers
simon3270
Hi @dfke. From the OP's output, there is no dpkg program running, so the "fuser" probably won't return anything. What seems to have happened is that a previous "apt-get upgrade" has failed badly, and not tidied up the lock file.
Also, a "kill -9" on a process gives it no chance to tidy up, so if it *was* a "dpkg" process holding the lock file, you have guaranteed that the lock file won't be removed. Always do a normal "kill" first, and only "kill -9" if the process still won't die.
dfke
Hi,
That's incorrect as it clearly states:
E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable) E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
Apt-get initiates dpkg but can't because some another process locks the /var/lib/dpkg/lock-frontend file which dpkg needs in order to run.
fuser /path - will tell you what pid is holding a file.
And... very bad idea to kill off these processes, as this can... sigh... more often than you might think... corrupt some APT cache file.
Even this isn't all this bad as usually the next apt-get update will fix most problems.
The ugliness occurs when cache files can't be repaired for some reason or the lock file lives, after a process is killed.
The APT subsystem periodically refreshes caches, so for a few seconds each day this lock file will show up.
Best to just wait a few seconds, then try again, likely your command will work then.
chalie001
ASKER
it return empty
sudo apt-get install docker-ce E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable) E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it? devops@devops-VirtualBox:~$ fuser /var/lib/dpkg/lock-frontend devops@devops-VirtualBox:~$
chalie001
ASKER
sudo lsof /var/lib/dpkg/lock-frontend lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME unattende 19098 root 5uW REG 8,1 0 2621866 /var/lib/dpkg/lock-frontend devops@devops-VirtualBox:~$ sudo kill 19098 devops@devops-VirtualBox:~$ sudo apt-get install docker-ce E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable) E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
From the "lsof" command, it looks as though an unattended upgrade is running. Look in the /var/lib/apt/periodic directory for the log files for this.
If you run the lsof again, you might find that the lock file is not being accessed by any program. In that case (and particularly if "ls -l" of the file shows it is old) , try deleting the file and running the apt-get command again.
If you do "kill nnn" to kill a process, run the "ps" check again to see whether it has actually stopped. A "kill" sends s signal to a process. By default, the process catches the signal and runs code which ends the process (closing files, releasing locks etc, then terminating). The process might, for various reasons, choose to ignore that signal, or simply note that it has arrived but just carry on running. The difference with "kill -9" is that the process doesn't receive a signal - the operating system simply terminates it. The "man" page for the program may describe what happens when various signals are sent to it.
Not entirely sure that this is how Experts Exchange works. The asker posting 2 commands from expert answers with no explanation then accepting them as the solution seems unhelpful.
Also do not use "kill -9" unless you have to. You will corrupt data. It's the same thing as always using "rm -rf" to delete things, even if you are only deleting a single file that you have just created. Unnecessary force will break things when a more gentle approach will achieve the required result safely.
in your first reply you ran fuser from a regular user prompt $. That's why you didn't see the pid as you needed to sudo. I clearly stated a root prompt #.
Obviously, there is no other matching process you're looking for...