On 01/09/16 00:12, Mark Martinec wrote:
I prefer to have a /var/run file system reside on a tmpfs
as its contents is small and ephemeral in its nature (like
pid files, lock files, sockets), need not be preserved across
reboots, and should not have to depend on any physical disk.
The problem is that some programs/services/ports like to create
their own subdirectory under /var/run. This works fine if such
subdirectory is created (when missing) by their rc.d script,
such as salt, dbus, jenkins, clamav-clamd, isc-dhcpd, kibana.
Unfortunately there are other ports which create a subdirectory
under /var/run at the installation time (pkg install). In this
case their subdirectory is missing on a reboot when /var/run
is re-created afresh, and they fail to start.
So my question is: are such ports (like influxdb, grafana3)
which do not create their subdirectory at a startup time
in error and a bug report is warranted, or am I wrong in
expecting that /var/run may be ephemeral and is such a setup
(as is common in Linux) unsupported?
I can't speak for FreeBSD policies, but as the person who implemented
/run on Debian GNU/Linux for sysvinit (/var/run on tmpfs essentially),
we had to audit every package and ensure that all packages created the
directories they needed if they weren't present. We retained the
cleaning of /var/run on boot to ensure a clean slate, so having it on
tmpfs was never mandatory, but if you did then it would just work.
However, we did have boot-time cleaning of /var/run for a while before
we introduced the tmpfs, so I can't recall doing anything but a handful
of minor tweaks.
Doing the same for FreeBSD wouldn't be too hard if you can automatically
scan the ports tree or build package contents to identify and fix any
packages which are providing static files.
Regards,
Roger
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"
