Re: git: 3418c14040f2 - stable/13 - libexec/rc: Add var_run rc script
- In reply to: deleted: "deleted (X-No-Archive)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 12 Sep 2022 13:17:14 UTC
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. Regarding diskless scenarios, my experience with SunOS 4.1.3 in a corporate training lab environment (installed by Sun prior to my joining the group), /var was an NFS share. IMO a newly created tmpfs /var used in this scenario is not only outside of the realm of this change but also significantly more complex because many files, not just directories, must be recreated and populated with data. In a sense you're asking for a freshly installed copy of /var with data saved from prior to reboot to be recreated for diskless workstations. Similar to the corporate training lab I maintained decades ago your diskless workstations should use NFS in such a scenario. > > 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