Artix Linux Forum

missing /run/lock

04 July 2023, 23:34:56

In a fresh base install /run/lock is missing. /var/lock is a symlink to /run/lock and this causes other problem, for example dinit is unable to start alsa service.
If i make the /run/lock dir, it is deleted after rebooting.
I had to manually create a lock.con file in /usr/lib/tmpfiles.d/ to solve the problem.

I would like to known why my previous installation i made last year (still working on another pc) has a persistant /run/lok dir, present in the filesystem also while running another distro from a different partition.

Thanks

ps
i don't even know  if the problem is dinit related, i found another post that suggests it should be common to others init system:
https://forum.artixlinux.org/index.php/topic,2214.new.html

Re: missing /run/lock

Reply #1 – 05 July 2023, 00:44:24

/run is created at, well, runtime since it's a tmpfs. After some investigation, it looks like dmraid is the package that installs the tmpfiles config that creates this file.

Re: missing /run/lock

Reply #2 – 05 July 2023, 13:15:59

Many thanks Dudemanguy,

is this issue to be considered a bug to report?

If other packages uses /run/lock, it should be created by, for example, dinit-rc (s6-rc etc).....

Re: missing /run/lock

Reply #3 – 05 July 2023, 21:19:03

Well on closer inspection, dmraid creates /run/lock/dmraid which, of course, also happens to make the /run/lock directory. It seems to have been installed as a dependency of something (according to pacman -Qi) but today nothing depends on dmraid package. So something changed at some point and it would explain why older installations don't have this issue (they probably have dmraid installed) I'm not sure if there's supposed to be a separate file or package that makes that directory. I took a brief peek at Arch's alsa-utils systemd services and it doesn't say anything about that directory either so I'm not even sure if Arch doesn't also have this problem in theory.

Re: missing /run/lock

Reply #4 – 14 July 2023, 03:42:14

Should be solved by an up to date etmpfiles (it has a legacy.conf now).