Alexander Bochmann wrote:
> ...on 2022-03-21 21:31:25, Bob Proulx via Dng wrote:
> > 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
>
> Actually what brought me on this track turns out
> to be the init script for acct, which has:
>

>  > LOCKFILE=/var/lock/subsys/acct
>  > [..]
>  >             touch $LOCKFILE

In that case it would be easy to either modify that variable or to
have the script mkdir the directory. Perhaps this added to that
script? Right before the existing touch?

    mkdir -p /var/lock/subsys
    touch $LOCKFILE

I am assuming that software is not native Devuan software. Because
the Devuan/Debian accounting package should work without these
modifications. But since I am assuming this has been ported from a
Red Hat system then it's likely that it might source a
/etc/sysconfig/acct or similar file. In which case I would look to
see if it is possible to override the setting there. Since I think
you would have seen an error on it not existing already in that case.
Maybe. I am making too many assumptions here.

> This is in turn run each night from the acct cron.daily
> script which rotates the accounting log files and restarts
> the service, producing a message that /var/lock/subsys/acct
> can't be touched...

Update to correct a mistake I made in my posting.

>>    mkdir /var/lock
>>    ln -s ../../run/lock /var/lock/subsys

I don't know why but when I looked I didn't see that on Devuan systems
/var/lock is a symlink too. It's already a symlink.

    lrwxrwxrwx 1 root root 9 May 25  2011 /var/lock -> /run/lock

For whatever reason I was confused and thinking it did not exist.
Which caused me to give poor advice for the system tweak workaround.
Because that would error on the mkdir (harmlessly) and put the symlink
in /run/lock/subsys which is a dynamically created tmpfs and it won't
persist across reboots. It just won't work as I had suggested.

Since /var/lock on Devuan is already a symlink to /run/lock that part
is okay and working without tweaks needed. However the foreign system
init script touching /var/lock/subsys/acct is probably the easiest to
modify to mkdir -p there before the touch instead. Then it will
always be created if needed and it will be needed once after every
system reboot.

Meanwhile... For Daedalus Testing and newer systems... A friend sent
me a direct reply with another alternate suggestion to install
"systemd-standalone-tmpfiles" which would be especially good if the
foreign software uses /etc/tmpfiles.d/acct.conf or similarly named
file already to create files. It exists starting in Daedalus Testing
and Ceres Unstable now but does not exist in Beowulf or Chimaera
though there is a backport for Chimaera.

I don't know very much about this systemd-standalone-tmpfiles package
and haven't tried it myself. But certainly if there were non-native
software that already expected to use the systemd tmpfilesd interface
in /etc/tmpfiles.d/* and one is running a Daedalus or newer system
then this seems like a reasonable solution to work this problem too.

> > And then a piece of software meant for Red Hat would run happily
> > without knowing it was on Devuan. At least for this portion.
>
> Thanks for the detailed explanation!

Happy to help! And I hope this discussion helps! :-)

Bob