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