E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 195 (apt-get) means another apt-get is still running and holds the package lock. Find that process with ps, let it finish, then run your command again.

The fix is to wait. In the test below the second install failed while the first was busy, and the same command succeeded as soon as the first one had exited with code 0.

The error

apt-get install -y curl
E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 195 (apt-get)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
exit code: 100

Why it happens

Two package operations were started at the same time. The first, apt-get install -y build-essential, was started in the background and was still running four seconds later (ps shows it at 00:04). The second, apt-get install -y curl, stopped at once with exit code 100. The message names the process that holds the lock, so you do not have to guess: here it was process 195.

On Ubuntu in WSL you meet this when a second terminal tab runs an install while the first is still busy, or when a setup script you started earlier is still working in the background. In this test, with no terminal attached, the second command was refused at once rather than queued.

The fix

First see what holds the lock. The process id from the message is in the list:

ps -o pid,etime,cmd -C apt-get
    PID     ELAPSED CMD
    195       00:04 apt-get install -y build-essential

Then wait for it to finish and run your command again:

first install exit code: 0
apt-get install -y curl > /tmp/second.log 2>&1
exit code: 0
tail -3 /tmp/second.log
Setting up libcurl4t64:amd64 (8.5.0-2ubuntu10.16) ...
Setting up curl (8.5.0-2ubuntu10.16) ...
Processing triggers for libc-bin (2.39-0ubuntu8.9) ...

The commands ran as root inside the container, so they carry no sudo; in your WSL terminal put sudo in front of apt-get. Deleting the lock files was not tested here and is not the fix: the lock is there because a process is using it, and the ps line shows that process is still alive. If the process in the list is one you started by mistake, finish or stop it in its own terminal rather than removing the lock under it.

How it was reproduced

The capture was made in an ubuntu:24.04 container (Ubuntu 24.04.5 LTS, apt 2.8.3, Docker Engine 29.9.2) standing in for Ubuntu in WSL. After apt-get update, a script started DEBIAN_FRONTEND=noninteractive apt-get install -y build-essential in the background, slept four seconds and ran apt-get install -y curl, which failed with the message above. After wait returned exit code 0 for the first install, the same curl install finished with exit code 0.

Frequently asked

How do I find which process holds /var/lib/dpkg/lock-frontend?
The error message names it, for example process 195 (apt-get). Run ps -o pid,etime,cmd -C apt-get to see that process with its full command line and how long it has been running.
How do I fix Could not get lock /var/lib/dpkg/lock-frontend in WSL?
Wait for the other apt-get to finish, then run your command again. In the test the second install failed with exit code 100 while the first was running and succeeded with exit code 0 after it had finished.
Should I delete /var/lib/dpkg/lock-frontend?
Not while the process named in the message is still running. The ps output shows whether it is alive; let it finish or stop it in its own terminal instead of removing the lock under it.

More decoded errors in the Fixes category. If the install itself fails inside a Dockerfile, see E: Unable to locate package in docker build.