Alexander Bochmann wrote: > ...on 2022-03-21 23:33:41, Alexander Bochmann wrote: > > I am running some software that expects the /var/lock/subsys directory > > to exist. It seems that this (and a few other directories) are created > > by /usr/lib/tmpfiles.d/legacy.conf, which is owned by systemd in Debian, > > and doesn't seem to exist in Devuan, or at least on my machine? > > Hrm, sending that mail out might have been slightly premature, > because it seems the whole tmpfiles.d stuff is a systemd thing > all around, and probably isn't even used on Devuan? I got confused > by existing config files which are shipped by a bunch of the > Debian packages...
It happens to all of us at times. No worries. However AFAIK the /var/lock/subsys directory is a Red Hat specific directory such as found on RHEL and Fedora for use for their init scripts. It doesn't have a use by other scripts. It is created by an init script at start time and removed by the init script at stop time. less /etc/rc.d/init.d/network # On a RHEL system... start) ... touch /var/lock/subsys/network stop) ... rm -f /var/lock/subsys/network It's used as a semaphore to ensure that init scripts don't run twice. The network could be started and then started again but since it had a semaphore in /var/lock/subsys then it would not run twice. Also on RHEL systems at least it is a symlink. lrwxrwxrwx. 1 root root 11 Jul 8 2019 /var/lock -> ../run/lock I think you are hitting a typical problem of porting software designed for one OS onto a different OS that has different conventions. That's not an unusual situation. It just means that the software and/or the system needs a tweak to make things work. I'll assume for the moment that this is only being used in an init script. If so then this is simply indicating that you will need to port the init script to Devuan. Which usually is pretty easy. And then after the init script has been created for Devuan there won't be a need for using /var/lock/subsys as that wasn't ever used on Debian. If this is not an init script and used in some other script or context then I go out on a limb and say that it was probably buggy. Because nothing else should have been using that directory. But a lot of corporate code is pretty poor quality. As a general statement about porting software it is sometimes easier to modify the system. Especially if use of something is buried layers deep in things. I have often made a symlinks as needed to make one system look like another flavor of system. Here it might be easy to create a /var/lock symlink just like on Red Hat systems and perhaps to also create a subsys directory. Here I might be inclined to create this adaptor layer. After looking to ensure there isn't a naming collision, probably won't be, then this can be statically created. mkdir /var/lock ln -s ../../run/lock /var/lock/subsys The /run and /run/lock directories are already created upon each boot. Therefore there is no need to create them. And since /var and /var/lock and /var/lock/subsys would be static there is no need to put anything into a boot time script as statically added is sufficient. And then a piece of software meant for Red Hat would run happily without knowing it was on Devuan. At least for this portion. Hope this helps on the topic of porting software. :-) Bob _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng