Re: [DNG] chimaera: no /usr/lib/tmpfiles.d/legacy.conf?
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
Re: [DNG] chimaera: no /usr/lib/tmpfiles.d/legacy.conf?
...on 2022-03-21 21:31:25, Bob Proulx via Dng wrote: > Alexander Bochmann wrote: > > 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 > 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 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 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... > 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! Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] chimaera: no /usr/lib/tmpfiles.d/legacy.conf?
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
Re: [DNG] chimaera: no /usr/lib/tmpfiles.d/legacy.conf?
...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... Sorry for the noise, Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] chimaera: no /usr/lib/tmpfiles.d/legacy.conf?
Hi - 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? If Devuan ships this file, does anyone know which package it belongs to? If it's missing completely, that's maybe something that should be fixed... Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
