Re: git: 3418c14040f2 - stable/13 - libexec/rc: Add var_run rc script

From: Cy Schubert <>
Date: Mon, 12 Sep 2022 15:02:19 UTC
In message <>, Helge Oldach 
> Cy Schubert wrote on Mon, 12 Sep 2022 15:17:14 +0200 (CEST):
> > In message <>, Helge Oldach 
> > writes:
> > > Cy Schubert wrote on Mon, 12 Sep 2022 02:41:14 +0200 (CEST):
> > > >     libexec/rc: Add var_run rc script
> > > >     
> > > >     Users with a tmpfs /var/run will lose the directory tree state of
> > > >     /var/run at reboot. This rc script will optionally (by default)
> > > >     capture the state of the directory structure in /var/run prior to
> > > >     shutdown and recreate it at system boot.
> > > >     
> > > >     Alternatively a user can save the state of the /var/run directories
> > > >     manually using service var_run save and disable the autosaving of
> > > >     /var/run state using the var_run_autosave variable, for those
> > > >     paranoid SSD users.
> > >
> > > I'm afraid this logic does not rhyme well with a common scenario: Firing
> > > up a tmpfs based /var by simply booting with a non-writeable /var which
> > > will trigger /etc/rc.d/var to create, mount and populate a tmpfs based
> > > /var. This is the classic diskless scenario.
> > >
> > > The concern is that var_run by default saves the var_run created mtree
> > > on exactly this tmpfs based /var (as /var/db/mtree/BSD.var-run.mtree) so
> > > it will be gone with the next reboot. This will void the var_run logic
> > > for the default case.
> > >
> > > I would suggest to document that tweaking var_run_mtree appropriately is
> > > necessary for such scenarios.
> > >
> > > Furthermore, I propose to consider extending the scope of var_run from
> > > /var/run to the whole of /var, which would be sensible in certain
> > > diskless cases as well.
> > 
> > Your scenario is outside of the scope of this change. This change was 
> > designed to support those who use a standard /var with a tmpfs /var/run, 
> > similar to Red Hat Linux support of /var/run.
> Indeed. I am trying to widen the scope by considering what /etc/rc.d/var
> does and put /etc/rc.d/var_run in perspective. With current defaults,
> var_run will not deliver as expected for the case of a volatile /var.
> In an abstract sense, /etc/rc.d/var and /etc/rc.d/var_run somewhat
> contradict.

In the FreeBSD sense, a tmpfs /var/run does contradict the of /var/run. But 
in comparison to the Linux or even Solaris definition we will see if this 
concept is embraced by people or not. This is why var_run is designed to 
run _after_ var, because an optional tmpfs /var/run is layered on top of 

To use this a person must have enough understanding that that the /var/run 
fstab line must follow the /var line. And the scope of this change is 
narrow. This is not to say that at some point in the future people may 
embrace a tempfs /var/run resulting in a redesign of the var and var_run rc 
scripts. I don't think we want to go down that path yet. This kind of 
change will require a paradigm shift not only in base O/S but also in ports 
and third party applications -- which is why the rc script was designed the 
way it was: to be as non-intrusive as possible while also providing a 
little extra flexibility to those who might want or even need it. This is a 
limited scope change and should remain that way until people think there 
should be significant changes to not only the architecture but also the 
FreeBSD ecosystem. Your suggestion is in fact a change not only to the 
architecture but the entire ecosystem which cannot be changed in a release, 
if ever.

> > Regarding diskless scenarios, my experience with SunOS 4.1.3 in a corporate
> I was more thinking about embedded scenarios where the root fs is
> readonly for a reason.

Embedded is a totally different kettle of fish. Those who use FreeBSD in an 
embedded environment will likely change not only /var but make significant 
other changes to the architecture. Facilitating a set of flexible but 
difficult to maintain configuration scripts (because of the flexiblity) IMO 
is outside of the scope of the FreeBSD project because every embedded 
application is different enough that each configuration would render such 
scripting generally useless. Someone writing some sample scripts or better 
yet some ports that when installed using pkg make the necessary 
configuration changes for embedded applications. But even that idea is 
flawed because an embedded application running inside of a TV is not the 
same as an embedded application running in a commodity router, 
manufacturing control robot, a lunar lander, or a smartphone. None of these 
embedded applications are remotely similar to each other and therefore the 
designers of such applications will undoubtedly need to write their own 
scripts tailored to their own embedded applications.

That's where spin-off projects can add value. They can create an embedded 
router, embedded firewall application or embedded load balancer. (Like the 
F5 I had here. It was a Linux O/S with an haproxy-like app and a web front 
end designed to run on an underpowered Pentium on a small amount of RAM 
with a tiny SD card for disk -- because hardware costs $$$ and inexpensive 
hardware improves profits.) Something like a pf based firewall or a NAS 
each with web front ends are excellent FreeBSD-based examples of this.

Remember, creep of scope will kill any project. I've been around long 
enough to see more than enough of that.

> Kind regards
> Helge

Cy Schubert <>
FreeBSD UNIX:  <>   Web:
NTP:           <>    Web: