Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Michael Biebl wrote:
> Russ Allbery schrieb:
[...]
>
>> in tmpfs and have the cleaning happen automatically without doing any
>> work. It simplifies the boot process and eliminates a whole class of
>
> I'm not sure I get that point. Why is the boot process simplified if now
> every script has to check for it's run directory and potentially create
> it or having to introduce fake boot scripts, which do nothing but create
> a run directory.
Why do you need fake boot scripts? I haven't seen you prove a fair use of
those.
It also appears that some are unused; I have the daemon running on my system
but there's an empty dir in /var/run without anything in there.
>
>> potential directory traversal races that you otherwise have to think
>> about. Potential additional boot speed from writing all the startup PID
>> files to a tmpfs file system (and benefits for flash drives as the only
>> system storage and similar special configurations) are just a bonus.
>
> I doubt, that the boot process will be faster if I have to fork a shell
> and create a run directory. And the /var/run directory is not something
> that is constantly written at, so I also doubt that it will buy you much
> of your flash drive life.
All those system calls (except forking the shell, which by the way should
already be in cache so no read from disk) cause no write operation on the
disk, which saves time, energy, and sector writes in SSDs.
>
> But let's be pragmatic, if we want to support both methods, why should
> we have to touch dozens (if not hundreds) of init script if I can do the
hundreds? I think you are exaggerating, why don't you provide real numbers?
> same with 10 lines of shell code (which does the backup/restore) and
> this problem is solved today. I don't think this solution is less
> elegant then fixing a myriad of init scripts.
>
As Russ already said, the FHS requires that all files in /var/run be deleted
on reboot; so there's a "myriad" of bogus init scripts.
Cheers,
Raphael Geissert
Reply to: