Running CURRENT (FreeBSD 14.0-CURRENT #109 main-n259294-dc58b3fca5e7: Fri Nov 18 09:26:42 CET 2022 amd64) and /var/run on tmpfs and having set var_run_enable="YES" (othervar_run_ tags untouched) in /etc/rc.conf seems not to have any influence whether tmpfs-based /var/run gets recovered in any way. One can easily checkout by installing port security/clamav and having /var/run tmpfs backed. While up and running installing the port security/clamav results in a working port. Rebooting with the above settings in /etc/rc.conf[.local] leaves clamav not working. By the way, /var/db is on non-volatile storage.
<https://github.com/freebsd/freebsd-src/commit/27b9777c28b4e9474bdc500c28d04feec48fbb84#diff-dab5ea80ff9507a517463fe9fc7751aa68fb7cd1709bc225b66e1c37f1f8c8feR19-R22> under # Set defaults: > : ${var_run_autosave:="YES"} ---- <https://www.freebsd.org/cgi/man.cgi?query=rc.conf&sektion=5&manpath=FreeBSD+14.0-current> does describe the boolean option: var_run_autosave – without stating a default. There's the description of behaviour when set to "NO", so readers _might_ assume that _without_ setting the boolean, it is effectively YES. ---- Here, _without_ using tmpfs: root@mowa219-gjp4-8570p-freebsd:~ # mount | grep run root@mowa219-gjp4-8570p-freebsd:~ # sysrc var_run_autosave var_run_autosave: NO root@mowa219-gjp4-8570p-freebsd:~ # sysrc var_run_enable var_run_enable: NO root@mowa219-gjp4-8570p-freebsd:~ # sysrc var_run_enable="YES" var_run_enable: NO -> YES root@mowa219-gjp4-8570p-freebsd:~ # sysrc var_run_autosave var_run_autosave: NO root@mowa219-gjp4-8570p-freebsd:~ # grep var_run /etc/rc.conf var_run_enable="YES" root@mowa219-gjp4-8570p-freebsd:~ # sysrc var_run_enable="NO" var_run_enable: YES -> NO root@mowa219-gjp4-8570p-freebsd:~ # date ; uname -aKU Sat Nov 19 07:22:08 GMT 2022 FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #25 main-n259004-2c10be9e06d4: Thu Nov 3 00:14:52 GMT 2022 grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400073 1400073 root@mowa219-gjp4-8570p-freebsd:~ #
(In reply to Graham Perrin from comment #1) Hello, I didn't assume that it is set to YES, the explanation for var_run_autosave states that it is active only for "restoring" purposes - assuming at boot time. Also, I tried on all boxes affected service var_run restart|start and checked for the content of /var/db/mtree, which remains empty in any way. Isn't it a bit confusing to name a service "_autosave" when it is in strictu sensu "_autorestore"?
Setting also var_run_autosave="YES" in rc.conf[.local] followed by service var_run restart seems to fullfill the expected purposes. Still, it is confusing. As mentioned earlier, setting ONLY var_run_enable="YES" and issuing service var_run restart does NOT have any affect.
Not a fix, but just a workaround. Run `serivce var_run save` as root before shutdown. Maybe because of the problem, it seems to be kept, but if something new which requires new directory structute in /var/run but creates them only installation are added, this should be done again. Put script below in /etc/rc.conf[.local]. An example for environments having clamav installed. As rc.conf is actually a /bin/sh script, this worked for me. The actual process (`test` to redirection) are borrowed from /etc/rc.d/var_run. if [ ! -d /var/run/clamav ] ; then test -f ${var_run_mtree} && \ mtree -U -i -q -f ${var_run_mtree} -p /var/run > /dev/null fi