Has anyone tested inn in F15. Bug 708627 suggests that it never was.
In addition to that bug, I think something keeps rm -rf-ing /var/run/news every time I reboot, which will keep inn broken even after this bug gets fixed. At least /var/run/news was missing after my first boot into F15, I fixed all off the above, but after the next reboot it was gone again.
On Sat, May 28, 2011 at 09:19:49 -0400, Sam Varshavchik mrsam@courier-mta.com wrote:
Has anyone tested inn in F15. Bug 708627 suggests that it never was.
In addition to that bug, I think something keeps rm -rf-ing /var/run/news every time I reboot, which will keep inn broken even after this bug gets fixed. At least /var/run/news was missing after my first boot into F15, I fixed all off the above, but after the next reboot it was gone again.
/var/run is now a tmpfs so data there will be lost at each reboot.
Bruno Wolff III writes:
On Sat, May 28, 2011 at 09:19:49 -0400, Sam Varshavchik mrsam@courier-mta.com wrote:
Has anyone tested inn in F15. Bug 708627 suggests that it never was.
In addition to that bug, I think something keeps rm -rf-ing /var/run/news every time I reboot, which will keep inn broken even after this bug gets fixed. At least /var/run/news was missing after my first boot into F15, I fixed all off the above, but after the next reboot it was gone again.
/var/run is now a tmpfs so data there will be lost at each reboot.
Splendid. Aside from the fact that inn's startup script does not get invoked correctly by initscripts, if you do invoke it correctly you also discover that it expects /var/run/news to be there, otherwise it bombs.
On 05/29/2011 12:19 AM, Sam Varshavchik wrote:
Splendid. Aside from the fact that inn's startup script does not get invoked correctly by initscripts, if you do invoke it correctly you also discover that it expects /var/run/news to be there, otherwise it bombs.
Appears the maintainer hasn't been active in a while since all these changes were well publicised ahead of time, guidelines published and a lot of packages have been changed to create these directories on boot if necessary. You can follow the guidelines listed at
http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
Rahul
Bruno Wolff III:
/var/run is now a tmpfs so data there will be lost at each reboot.
Sam Varshavchik:
Splendid. Aside from the fact that inn's startup script does not get invoked correctly by initscripts, if you do invoke it correctly you also discover that it expects /var/run/news to be there, otherwise it bombs.
Hmm, is it right or wrong for *anything* to expect the contents of /var/run to remain after a reboot?
I would have expected /var/run should be volatile, like /tmp.
On 05/29/2011 09:05 AM, Tim wrote:
Hmm, is it right or wrong for *anything* to expect the contents of /var/run to remain after a reboot?
I would have expected /var/run should be volatile, like /tmp.
Right but a change for Fedora 15 exposes this issue for software that doesn't cope with it well
http://fedoraproject.org/wiki/Features/var-run-tmpfs
Rahul
Tim wrote:
Bruno Wolff III:
/var/run is now a tmpfs so data there will be lost at each reboot.
Sam Varshavchik:
Splendid. Aside from the fact that inn's startup script does not get invoked correctly by initscripts, if you do invoke it correctly you also discover that it expects /var/run/news to be there, otherwise it bombs.
Hmm, is it right or wrong for *anything* to expect the contents of /var/run to remain after a reboot?
There is a benefit to cleaning out the lock files, but there is a definite problem to cleaning out everything, since the directory structure is needed to support the lockfiles. Having the program create the structure is possible, but: - it moves complexity from the install to the program - it means more code needs to be added to check that the app is actually installed at all - it is one more distribution sensitive thing to add to config
Personal opinion: if shutdown saved the directory structure but not the lockfiles, and startup repopulated /var/run when it was created, then maintainers wouldn't have to be hacking multiple applications to add code which seems not to be needed in some/most/all other distributions.
Someone obviously didn't like the "least work" approach.
I would have expected /var/run should be volatile, like /tmp.
/tmp isn't volatile. At least not in the sense that everything is removed over every boot. At least not in Fedora <15, haven't looked to see if a reboot loses all work in progress there.
Bill Davidsen writes:
Tim wrote:
Bruno Wolff III:
/var/run is now a tmpfs so data there will be lost at each reboot.
Sam Varshavchik:
Splendid. Aside from the fact that inn's startup script does not get
invoked
correctly by initscripts, if you do invoke it correctly you also discover that it expects /var/run/news to be there, otherwise it bombs.
Hmm, is it right or wrong for *anything* to expect the contents of /var/run to remain after a reboot?
There is a benefit to cleaning out the lock files, but there is a definite problem to cleaning out everything, since the directory structure is needed to support the lockfiles. Having the program create the structure is possible, but:
- it moves complexity from the install to the program
Only if "program" includes the packaged initscript. If the main app expects to see something persistent in /var/run, but its state does not really persist across reboots and there's not a lot of stuff there, the fix seems to be easily doable in the initscript. In this case, the initscript is fixed fairly easily by mkdiring /var/run/news itself, and setting the right environment variable to keep /etc/rc.d/init.d/function from pulling the rug out from under my feet.
Having the initscript recreate what the app expects in /var/run seems to be the obvious solution that does not require patching upstream source. Although I have sufficient spare cycles now, I anticipate that I won't in the future, and I don't want to take inn myself just to have to abandon it later.
On 05/29/2011 07:49 PM, Bill Davidsen wrote:
There is a benefit to cleaning out the lock files, but there is a definite problem to cleaning out everything, since the directory structure is needed to support the lockfiles. Having the program create the structure is possible, but:
- it moves complexity from the install to the program
- it means more code needs to be added to check that the app is actually installed at all
- it is one more distribution sensitive thing to add to config
It doesn't have to be any of this as referenced from the feature proposal. Just in case, you didn't read it.
http://fedoraproject.org/wiki/Packaging:Tmpfiles.d
Rahul
Rahul Sundaram wrote:
On 05/29/2011 07:49 PM, Bill Davidsen wrote:
There is a benefit to cleaning out the lock files, but there is a definite problem to cleaning out everything, since the directory structure is needed to support the lockfiles. Having the program create the structure is possible, but:
- it moves complexity from the install to the program
- it means more code needs to be added to check that the app is actually installed at all
- it is one more distribution sensitive thing to add to config
It doesn't have to be any of this as referenced from the feature proposal. Just in case, you didn't read it.
The page you note has a big warning that it doesn't work in EPEL and FC<15. How does that address the distribution dependent feature issue?
Fedora has limited manpower. By save/restore of the directory structure no one has to go into the original package and change anything. Less work for maintainers, reduce or eliminate the possibility that something will not get modified until it breaks, etc.
A proposed solution which makes it easy to do unnecessary work on every application is not an optimal solution compared to "we changed it, we will avoid breaking applications and make it work."
On 06/01/2011 02:09 AM, Bill Davidsen wrote:
The page you note has a big warning that it doesn't work in EPEL and FC<15. How does that address the distribution dependent feature issue?
It makes it more distribution consistency in practise because major distributions except Fedora were already using /var/run as tmpfs. We can't retroactively change previous distro releases but we can bring more consistency going forward since distributions are standardizing on systemd mostly and upstart has a similar implementation as well.
Rahul
On 05/28/2011 06:31 AM, Bruno Wolff III wrote:
/var/run is now a tmpfs so data there will be lost at each reboot.
I was about to ask why, when something went <click!>. Programs that need to make sure there's only one copy of them running (e.g., yum) use /var/run for their lockfiles so cleaning it out at boot avoids having programs refuse to run because of a stale lockfile from the last session.
-
Bill Davidsen -
Bruno Wolff III -
Joe Zeff -
Rahul Sundaram -
Sam Varshavchik -
Tim