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 at 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 at 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 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. -- Michael hennebry at web.cs.ndsu.NoDak.edu "Sorry but your password must contain an uppercase letter, a number, a haiku, a gang sign, a heiroglyph, and the blood of a virgin." -- someeecards