Re: Using TMPFS for /tmp and /var/run?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/29/2012 13:52, Xin Li wrote:
> On 03/29/12 09:41, Chris Rees wrote:
>> On 29 Mar 2012 16:49, "O. Hartmann" 
>> <ohartman_at_mail.zedat.fu-berlin.de> wrote:
>>> 
>>> I was wondering if there are some objections using TMPFS for
>>> /tmp and /var/run. I figured out some problems with some rc.d
>>> scripts when using TMPFS for /var/run, samba and OpenLDAP do
>>> store some informations like PID in a subfolder of their own in
>>> /var/run, but the rc.d scripts are not checking properly the
>>> existence of the appropritae folder (unlike "dbus" and "hald",
>>> they check properly!).
>>> 
>>> I already submitted two PRs, but for SAMBA, my "hack" is
>>> trivial and obviously to clumsy, so it should be check
>>> properly.
>>> 
>>> My question is whether there are objections using TMPFS for
>>> bot /tmp/ and /var/run/ at this stage on FreeBSD
>>> 10.0-CURRENT/amd64?
> 
>> Any rc script that complains about an empty /var/run is buggy-
>> it should be assumed that it will be emptied on boot.
> 
> Agreed.  We may want a generic way of registering custom mtrees
> (or something) that creates the hierarchy on boot, by the way.
> 
> Currently this has to be done by individual rc.d scripts if they
> need a separate directory.

I think there is some confusion here, so hopefully I can help clear it
up.

For BASE rc.d scripts, definitions for needed subdirectories and their
permissions for /var/run are located in /etc/mtree/BSD.var.dist, which
is called by /etc/rc.d/var at boot time. Anything IN THE BASE that
complains about a missing directory in /var/run needs to be fixed, and
should be reported.

For PORTS rc.d scripts, they are expected to create (or check for the
existence of) the needed directories/permissions *in the script* (not
at port/package install time, this is why). Any variations on that
theme should also be reported.

In short, there is nothing in rc.d (ports or base) that should fail if
you start with an empty /var/run. If it does, it's a bug.

Meanwhile, as much as I find it personally distasteful, I can't
imagine us changing the default for clear_tmp_enable at this point.

hth,

Doug

- -- 

    This .signature sanitized for your protection
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJPeiaxAAoJEFzGhvEaGryEefQH/14QUKTun4njDF6YHHPlBcqz
1Ky97Dlu3cka9rNee8y7aJWSK61mg/OjacjgViKrrA6isOg/wsaJ6qK9XCk1Npb/
ZKEvszPvdHcdy+XA78HS/UTa1Pqxx+H6UPiF2s0f80LkP468UthfszXXhw8jJbSh
dWG9OluprWd/21iHco5S/V+i0zgcEHHkdWAT+N5+w4Cw8cUiVk+hV90YpUK9PnO4
bzfvqppP9tCdnt9J/q8bUwNy4iK3orfSMRZ5SFFpKqeUTI4fbY3CuZHsEXf1AXQI
LhVlRoCa35exFv5k9ivJ3IJMorNsLSulXluCrULn38yvtlRSazWWFCcVha18mbs=
=cPrk
-----END PGP SIGNATURE-----