linux-lockfiles service
The /var/lock directory on various Linux operating systems is considered outmoded.
It has two uses:
It was used by the old van Smoorenburg rc system to try to prevent multiple instances of a single service from being run by accident.
Under an actual service manager, this is of course superfluous.
The service manager ensures that by its very nature.
It is used by subsystems that want to negotiate access to things like serial devices that can be used both for dial-out and for dial-in login.
The linux-lockfiles service (which is only built and packaged on Linux operating systems, of course) is currently preset to "enabled" and its preset is packaged as one of a handful of "boot essential" services.
This service creates /run/lock at bootstrap, which is where Linux operating systems nowadays point /var/lock to with a symbolic link.
In theory, you should also create an /etc/fstab entry for mounting a memory filesystem on top of /run/lock (which the /etc/fstab import subsytem will convert into a mount@-run-lock service bundle, which in turn the linux-lockfiles service bundle orders itself before).
This is because in theory unprivileged users can otherwise attack /run (which they cannot write to) by filling up/run/lock which (alas, for Debian Linux compatibility) they can write to.
In practice, this is just papering over the cracks, and the better approaches are:
Just do not use linux-lockfiles at all, with a system-administrator-written preset (to disable it) that overrides the (intentionally low priority and overridable) "boot essentials" one that comes in the package.
Make /run/lock not world-writable.
It is marked as "restricted write access", allowing the world to create files there with restricted permissions on how users can affect one anothers' files and directories.
This approach involves not making it world-writable at all, and letting only the programs that want to negotiate device access have the ability to create and delete files there.