Date: Mon, 12 Sep 2022 08:02:19 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: freebsd@oldach.net (Helge Oldach) Cc: Cy.Schubert@cschubert.com, cy@FreeBSD.org, src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-branches@FreeBSD.org Subject: Re: git: 3418c14040f2 - stable/13 - libexec/rc: Add var_run rc script Message-ID: <20220912150219.89758282@slippy.cwsent.com> In-Reply-To: <202209121405.28CE5r8m053976@nuc.oldach.net> References: <202209121405.28CE5r8m053976@nuc.oldach.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <202209121405.28CE5r8m053976@nuc.oldach.net>, Helge Oldach writes: > Cy Schubert wrote on Mon, 12 Sep 2022 15:17:14 +0200 (CEST): > > In message <202209120716.28C7Gjd2091559@nuc.oldach.net>, 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 /var. 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 -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org NTP: <cy@nwtime.org> Web: https://nwtime.org e^(i*pi)+1=0
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220912150219.89758282>