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
signature.asc
Description: PGP signature
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng