Hi,
what keeps deleting files and directories under /var/run? Having them deleted is extremely annoying because after a reboot, things are suddenly broken because services don´t start.
On Sep 21, 2017, at 8:14 AM, hw hw@gc-24.de wrote:
what keeps deleting files and directories under /var/run? Having them deleted is extremely annoying because after a reboot, things are suddenly broken because services don´t start.
Assuming that this is a CentOS 7 system, /var/run is just a link to /run, which is a tmpfs filesystem. No files there survive a reboot.m
If you need directories to be automatically created, you’ll need to use systemd-tmpfiles. Basically, the packages put files in /usr/lib/tmpfiles.d/, and you’d add your own in /etc/tmpfiles.d/.
For example, fail2ban has:
$ cat /usr/lib/tmpfiles.d/fail2ban.conf D /var/run/fail2ban 0755 root root -
Read the ‘tmpfiles.d’ man page for more details.
-- Jonathan Billings billings@negate.org
On 09/21/2017 08:14 AM, hw wrote:
what keeps deleting files and directories under /var/run? Having them deleted is extremely annoying because after a reboot, things are suddenly broken because services don´t start.
You've received a lot of advice, criticism, and information from this original post, and I'm not going to rehash any of those things. If you're not expecting it,the current CentOS 7 behavior could easily be jarring, to say the least. I empathize with your situation; the release notes are large, dense, and it's easy to miss something that has been changed, like this behavior (or like the need to 'yum downgrade' a packge to get a 'yum update' to complete).
However, whether we like it or not, CentOS is a rebuild of the sources for the upstream enterprise Linux. The underlying issue is one of two different package maintainers having differing ideas (as well as two differing interpretations of admittedly ambiguous standards) of what the system should do. If I see two reasonable, competent, system administrators disagreeing about the interpretation of a standard, then the standard is ambiguous. Now, I'm not going to pass judgment on whether it's a bug or a feature, nor am I going to say which I think it is, because what I think or feel about it won't change the reality of the situation; this distribution is way too far down the development curve now -- the time to express those opinions where such expression might have made a difference in the reality of the situtaion was back while the change was being considered for Fedora, and that was a long time ago.
The fact of the matter is that the EL7 behavior is to store /var/run in a temporary way, and that's not at all likely to be changed in EL7, regardless of the opinions I have or express about it or what expletives I choose to call it. EL7 includes mechanisms so that files, directories, sockets, named pipes, or whatever that need to look like they persisted across a reboot in /var/run can be recreated at boot as needed, and the packages you use do not yet use that mechanism.
If the maintainers of packages that want to run well on CentOS 7 need to have /var/run/$some-file persistence (or pseudo-persistence, which is the current behavior enabled by re-creating said files) then those maintainers will need to change their packages to match actual behavior or file a bug report with upstream to change the behavior. Upstream will probably close with a 'WONTFIX' and the package maintainer will either change packaging or stop supporting CentOS 7. Of course, stranger things have happened, and upstream might relent on the decision. But my gut feel is that upstream will keep the current behavior and the packages will eventually be changed to support it, but I always reserve the right to be wrong.
On 10/11/2017 12:20 PM, Lamar Owen wrote:
On 09/21/2017 08:14 AM, hw wrote:
what keeps deleting files and directories under /var/run? Having them deleted is extremely annoying because after a reboot, things are suddenly broken because services don´t start.
*snip*
The fact of the matter is that the EL7 behavior is to store /var/run in a temporary way, and that's not at all likely to be changed in EL7,
*snip*
When I need daemon (or other not human user) produced data to persist a reboot, I use /srv - I don't know if that is technically correct or not, but it seems highly unlikely /srv would ever be a candidate for wipe on boot.
Perhaps the package in question could simply be patched to use /srv ??
On 10/11/2017 03:42 PM, Alice Wonder wrote:
When I need daemon (or other not human user) produced data to persist a reboot, I use /srv - I don't know if that is technically correct or not, but it seems highly unlikely /srv would ever be a candidate for wipe on boot.
Perhaps the package in question could simply be patched to use /srv ??
Hmm, not a bad idea actually, although historically with 'Old Unix (TM)' I would probably use /usr or /var/lib (if it's new enough to have /var/lib). Yes, /usr, not /usr/lib or /usr/share; my first Unix system place user home directores right off of /usr (I had my /usr/lowen from my Tandy 6000 Xenxi system on 30 8-inch floppies once; kindof wish I had those again, although enough of them would probably be unreadable so I would lose some segments of the multi-floppy tar; but the readable segments could still be restored, since it was an uncompressed tar.....).
Today I would say a directory tree right off of /var or /srv wouldn't be inappropriate.
On Wed, 11 Oct 2017, Lamar Owen wrote:
If the maintainers of packages that want to run well on CentOS 7 need to have /var/run/$some-file persistence (or pseudo-persistence, which is the current behavior enabled by re-creating said files) then those maintainers will need to change their packages to match actual behavior or file a bug report with upstream to change the behavior. Upstream will probably close with a 'WONTFIX' and the package maintainer will either change packaging or stop supporting CentOS 7. Of course, stranger things have happened, and upstream might relent on the decision. But my gut feel is that upstream will keep the current behavior and the packages will eventually be changed to support it, but I always reserve the right to be wrong.
I see at least two possible intermediate results: The RHEL 7 folks do something, perhaps make a package, to make pseudo-persistence super easy to get. The RHEL 7 folks do something, perhaps make a package, to allow users to fix this particular problem, e.g. by adding pseudo-persisitence for a file used by a package.
My guess is that neither would have to be done by the RHEL 7 folks. They might want to to ensure that neither gets done badly.
On 13/10/2017 16:02, Michael Hennebry wrote:
Hi Michael,
I see at least two possible intermediate results: The RHEL 7 folks do something, perhaps make a package, to make pseudo-persistence super easy to get. The RHEL 7 folks do something, perhaps make a package, to allow users to fix this particular problem, e.g. by adding pseudo-persisitence for a file used by a package.
I disagree vehemently. Please STOP giving any advice or making any suggestions along the lines of persisting /var/run. It *is* meant to be volatile. Anyone who is packaging an application for CentOS 7 must realise this, and package their application accordingly. NO OTHER SOLUTION is acceptable.
Folks, please stop giving bad advice or suggesting horrible hacks.
Stop trying to force a square peg into a round hole.
Cheers, Anand
On 10/13/2017 10:19 AM, Anand Buddhdev wrote:
.. Stop trying to force a square peg into a round hole.
Whee, I just _know_ I'm going to be positively skewered (and maybe even plonked!) for this.... but, hey, it's Friday, and this post is meant to be a bit funny. So lighten up, and enjoy a short read.
obHumor: I actually have a piece of furniture (a small table) with square pegs in round holes. The spaces between the sides of the square peg and the round hole are filled with a color-contrasting glue, and the result is rather pretty. :-) I intentionally picked this furniture specifically because of the square pegs in the round holes.....
obHistory: Cobblers making boots back in the mid to late 1800's would often use square wooden pegs in round leather holes (typically for the thick leather soles of the boots) so that the peg would 'swage' it's own hole and fit tighter, thus holding better than a round peg ever could. (Reference: "Farmer Boy", Laura Ingalls Wilder, Chapter titled 'Cobbler' (hey, I have five kids; my wife and I have read through the whole series five times!) which, after reading through it with my eldest child back in 2000 or so I decided to never use the 'square pegs in rounds holes' proverb ever again!). (There are other historical instances of square pegs being better for round holes than round pegs, especially when you didn't want the peg to rotate in the hole).
Anyway, a form of pseudo-persistence that meets the OP's needs is already supported directly by systemd-tmpfiles, which is a part of the core systemd package and non-optional, so your vehement disagreement is moot, sorry. The round hole already has a square-peg adapter, at least in CentOS 7. Packagers just need to select the proper 'adapter' for systemd-tmpfiles; the adaptation is not (and should not be, in my opinion) automatic.
On 13/10/2017 18:45, Lamar Owen wrote:
Hi Lamar,
[snip]
I do appreciate your humour :)
Anyway, a form of pseudo-persistence that meets the OP's needs is already supported directly by systemd-tmpfiles, which is a part of the core systemd package and non-optional, so your vehement disagreement is moot, sorry. The round hole already has a square-peg adapter, at least in CentOS 7. Packagers just need to select the proper 'adapter' for systemd-tmpfiles; the adaptation is not (and should not be, in my opinion) automatic.
systemd-tmpfiles is not a hack, nor is it an adaptor. It's a core part of systemd, and is meant to be used as has been described many times in this thread.
What I am very much against are the various suggestions to save /var/run on shutdown and restore it, or other pseudo packages to do similar stuff. None of that is needed. systemd-tmpfiles is the correct and only way to create files and directories in /var/run (and any other place) as needed.
On 10/13/2017 10:02 AM, Michael Hennebry wrote:
I see at least two possible intermediate results: The RHEL 7 folks do something, perhaps make a package, to make pseudo-persistence super easy to get. ...
This already exists as systemd-tmpfiles, as was mentioned in the thread by someone else. Any packages needing anything to be initialized in /var/run (sockets, named pipes, etc) should use that mechanism for those things to be created each boot; that's why I used the term 'pseudo-persistence' as the persistence of this information is a mirage.
-
Alice Wonder -
Anand Buddhdev -
hw -
Jonathan Billings -
Lamar Owen -
Michael Hennebry