Was inn tested for F15

[Sam Varshavchik]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20110529/6c059a77/attachment.bin