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.
9 thoughts on - /var/run/… Being Deleted :((
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
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.
*snip*
*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 ??
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).
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.
Hi Michael,
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
This already exists as systemd-tmpfiles, as was mentioned in the thread by someone else.
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.
Hi Lamar,
[snip]
I do appreciate your humour :)
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.
9 thoughts on - /var/run/… Being Deleted :((
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
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.
*snip*
*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 ??
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).
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.
Hi Michael,
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
This already exists as systemd-tmpfiles, as was mentioned in the thread by someone else.
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.
Hi Lamar,
[snip]
I do appreciate your humour :)
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.