issue killing process

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...

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!.

The line...

devops   12626  0.0  0.0  21532  1044 pts/0    S+   06:31   0:00 grep --color=auto -i dpkg

Select allOpen in new window

Refers to the grep your running, which has already ended when you have a shell prompt again, so kill will fail, as process has already completed/died.

Hi,

# fuser /var/lib/dpkg/lock-frontend

This should output the PID or PID's that keep it locked. Then sudo kill -9 on those and try again.

Cheers

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.

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.

Cheers

Follow @dkfe's suggestion.

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.

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:~$

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.

sudo lsof /var/lib/dpkg/lock-frontend

Select allOpen in new window

sudo kill -9 process_id

Select allOpen in new window

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.

Hi,

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 #.

Cheers