In message <20220827082638.57901a72@slippy>, Cy Schubert writes: > On Sat, 27 Aug 2022 15:38:44 +0200 > Juraj Lutter <o...@freebsd.org> wrote: > > > > On 27 Aug 2022, at 15:27, Michael Gmelin <gre...@freebsd.org> wrote: > > >=20 > > >=20 > > > =20 > > >> On 27. Aug 2022, at 15:18, free...@oldach.net wrote: > > >>=20 > > >> =EF=BB=BFMichael Gmelin wrote on Sat, 27 Aug 2022 15:02:04 +0200 (CEST= > ): =20 > > >>> (you're removing /var/run, which shouldn't be removed =20 > > >>=20 > > >> Not quite. It's actually not uncommon to boot with an empty /var. Plea= > se see /etc/rc.d/var and related. =20 > > >=20 > > > That=E2=80=99s a good point. > > > =20 > > >> The request that ports/packages should consider this case is not exact= > ly unreasonable IMO. > > >> =20 > > >=20 > > > If I was the maintainer, I would simply add the code to create the dire= > ctory for robustness sake (I for one deleted subdirs in /var/run more than = > once and would expect a port to fix this on restart, also to make sure corr= > ect permissions are applied). But since it doesn=E2=80=99t seem like this i= > s going to happen, adding a custom rc file would be a viable short term wor= > karound for the requester. > > >=20 > > > I like the idea of having something like tmpfiles.d, it would also help= > port maintainers (could also be done as a port). > > > =20 > >=20 > > As I have stated in one of those PR: clamd creates file in two locations: > >=20 > > - PidFile > > - LocalSocket > >=20 > > Both the locations could be checked by rc.d script in clamd.conf (also fr= > eshclam eventually) and respective directories can be created from within s= > tart_precmd() > >=20 > > otis > >=20 > > =E2=80=94 > > Juraj Lutter > > o...@freebsd.org > >=20 > > As stated before in this thread, replacing /var/run with tmpfs is not a > supported configuration. However if users wish to replace /var/run > with tmpfs they can create an rc script (I put my extra rc scripts in > /etc/local/rc.d) to create the hierarc > If one does this they can either use mtree(1) to create the hierarchy > or simply take a snapshot (find /var/run -type d | cpio -o > > /etc/local/my_var_run.cpio), having their rc script recreate the > hierarchy using cpio -i < /etc/local/my_var_run.cpio). And > be periodically updated the archive as needed, probably through a > shutdown script. > > One will notice that /etc/mtree/BSD.var.dist shows us what is created > in /var/run by default during installworld. > > The change requested is not specifically for an individual port but > essentially a FreeBSD-wide infrastructure change. I don't think this > is reasonable without a lot of consideration about what will be broken > during the process of changing build and boot processes and the > potential POLA fallout from such a change. A change like this needs to > be architected. > > I don't think this is the mailing list to discuss this topic. This > should be discussed on ports@. Not here. Maybe it should be moved there > as this is a ports not a base O/S issue.
This will resolve the problem: #!/bin/sh # PROVIDE: kq-var-run # REQUIRE: zfs tmp # BEFORE: FILESYSTEMS . /etc/rc.subr name=kq_var_run rcvar=kq_var_run_enable extra_commands="update create" start_cmd="kq_var_run_start" create_cmd="kq_var_run_create" update_cmd="kq_var_run_create" # stop_cmd="kq_var_run_create" load_rc_config $name # Set defaults : ${kq_var_run_enable:="NO"} : ${kq_var_run_mtree:="/etc/local/mtree/KQ.var-run.mtree"} kq_var_run_start() { df -ttmpfs /var/run > /dev/null 2>&1 && mtree -f ${kq_var_run_mtree} -p /var/run } kq_var_run_create() { mtree -cbdj -p /var/run > ${kq_var_run_mtree} } run_rc_command "$1" A person could add stop_cmd="kq_var_run_create" to save the /var/run mtree at shutdown instead of manually. Works with tmpfs /var/run. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org NTP: <c...@nwtime.org> Web: https://nwtime.org e^(i*pi)+1=0