/var/lock is a bad symlink as of 3.21

[m90]

I'm distributing an image based off alpine. The build starts failing when updating alpine from 3.20 to 3.21 as it seems /var/lock, which used to be a plain directory is now a symlink to /run/lock, but does not resolve properly:

➜  ~ docker run --rm alpine:3.20 stat -L /var/lock
  File: /var/lock
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: 5ah/90d Inode: 5375239     Links: 3
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-12-10 09:47:26.652268132 +0000
Modify: 2024-09-06 11:34:04.000000000 +0000
Change: 2024-12-10 09:47:26.636267951 +0000
➜  ~ docker run --rm alpine:3.21 stat -L /var/lock
stat: can't stat '/var/lock': No such file or directory

It seems /run is empty on a fresh container, so the symlink to /run/lock does not work as intended:

➜  ~ docker run --rm alpine:3.21 stat /var/lock   
  File: '/var/lock' -> '../run/lock'
  Size: 11              Blocks: 0          IO Block: 4096   symbolic link
Device: 5ah/90d Inode: 5375776     Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-12-05 12:17:42.000000000 +0000
Modify: 2024-12-05 12:17:42.000000000 +0000
Change: 2024-12-10 09:47:35.407367086 +0000
➜  ~ docker run --rm alpine:3.21 ls -lah /run  
total 8K     
drwxr-xr-x    2 root     root        4.0K Dec  5 12:17 .
drwxr-xr-x    1 root     root        4.0K Dec 10 09:57 ..

I could obviously just start creating the directory in my Dockerfile, but I am not entirely sure if this is intended.

man hier seems to tell me I can expect /var/lock to exist:

       /var/lock
              Lock  files  are placed in this directory.  The naming convention for device lock files is LCK..<device> where <device> is the device's name in the filesystem.  The format used is that
              of HDU UUCP lock files, that is, lock files contain a PID as a 10-byte ASCII decimal number, followed by a newline character.

[davinkevin]

Same issue for us, and so, +1.

We adopted the mkdir /run/lock approach and wait for a bug fix (I was writing the issue while you opened it).