Re: pkg/52143: net/quagga does not start on boot

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR pkg/52143; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/52143: net/quagga does not start on boot
Date: Sat, 08 Apr 2017 09:04:18 +0700

     Date:        Fri,  7 Apr 2017 21:00:02 +0000 (UTC)
     From:        DOYASHIKI Shinichi <clare%csel.org@localhost>
     Message-ID:  <20170407210002.2EFBF7A2BC%mollari.NetBSD.org@localhost>
 
 
   |  I resolved by following configuration:
 
   |  1) patching /etc/rc.d scripts
 
   |  2) adding "/var" and "/usr" to ciritical_filesystems_local
   |     parameter in /etc/rc.conf
 
 Of those, change 2 would have allowed quagga to start at boot time (and
 from this it seems that your /usr/pkg is a part of /usr).  /var is generally
 in critical_filesystems_local by default anyway, but /usr (which is
 sometimes NFS mounted) is in critical_filesystems_remote which needs
 networking operational first - changing that to be in 
 critical_filesystems_local (when it is a local filesystem) is a common need.
 
 The changes in 1 alter just when it starts relative to other processes.
 
 Change 1 is another example (we saw another with openvpn just a couple of
 weeks ago) where the network startup ordering in the rc scripts is
 just not quite right (particularly when sites want to add more networking
 daemons from pkgsrc and they need to be started in the right place.)
 
 I think I will look at rationalising the base netbsd networking rc.d
 scripts (the PROVIDE/BEFORE/REQUIRE lines) before I'd consider adding
 patches to quagga to change its startup order,   The changes that add
 BEFORE NETWORKING are probably what is wanted everywhere, but the change
 to the REQUIRE line in rc.d/zebra (while I expect fine for your usage)
 is just too specific to do it that way, we need (at least one, probably two)
 intermediate pseudo-steps (targets like NETWORKING) which can be used
 instead.
 
 This also reminds me of an earlier suggestion to allow rc.conf to be
 able to override the REQUIRE/BEFORE steps of (selected) rc.d scripts
 to allow sites to more easily make the ordering match local requirements
 without needing to go edit the scripts themselves (which would make
 system upgrades far easier for those who need this.)
 
 kre