apt-install does not create lock

[mjoppich]

While performing a

sudo apt-get upgrade

I can open another Bash on Ubuntu on Windows and do a

sudo apt-get install build-essentials

which then both crashes. But I suspect the first apt-get updgrade should have created a lock in /var/lock/ ?

Currently running Insider Builds 15031.

[benhillis]

We do not own the apt binary, and this seems to be an issue in user-mode. Relying on the behavior the presence of a folder that that user can delete seems like a bad idea.

I haven't ever seen this locally. Did you do anything in particular like delete things in the /var directory?

[mjoppich]

I have tried to not mess with the /var/ directory, but I can check whether this behaviour still occurs the next days.
Unfortunately then on a "rather" clean install of BoW, as I checked out the current windows store WSL bash yesterday.
So maybe this is fixed by now ...

[aseering]

@benhillis -- "relying on the behavior ... bad idea" -- welcome to Linux command-line tools :-) Though, in this case, it looks to me like this is in fact a kernel (WSL) bug or limitation.

I am able to reproduce this reliably on my own machine, using build 15031. My repro is as follows:

• Open two terminal windows, in a clean WSL install that has neither of the following two large packages already installed (any two big packages should do; the install just needs to take enough time that you can get both going at once)
• In window 1:

sudo apt install eclipse

• In window 2, simultaneously:

sudo apt install libreoffice

Expected:

• One of the commands will error out, unable to acquire a lock

WSL:

• Both commands attempt to proceed concurrently

If I strace one of the two commands, I see the following:

open("/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4
fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
fcntl(4, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = 0

/var/lib/dpkg/lock exists on my machine. It has correct permissions. The kernel (well, WSL) is granting apt an exclusive lock on that file. In fact, it is apparently generously granting two exclusive locks on that file at the same time. That ain't right :-)

[benhillis]

@aseering - thanks for the additional information. I know our file locking implementation is incomplete, I'll take a look and see if I can see what's going on.

[alainfrisch]

FWIW, I found out that flock seems to work correctly under WSL 1, contrary to lockf and fnctl-based locking. Of course, it is "less powerful", but for some applications, it is good enough.

[earonesty]

Note: this issue is duplicated by #1927, which should probably be the primary ticket.

[benhillis]

/dupe #1927

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists in this repository. This specific instance is being closed in favor of tracking the concern over on the referenced thread.

Thanks for your report!