rc: make 'ddb' and 'dumpon' require disks, not the other way around

[trasz]

Summary

Previously the 'dumpon' script would require to be run before 'disks'
(geli, gbde, ccd). This looks backwards. This change makes it match
the ordering of the 'swap' rc script.

[chuck]

This makes sense to me, but I'm not an expert on these scripts.

[ngie]

This needs to be run through rcorder to ensure things haven't been broken. Please add the output of this information to the CR.

[trasz]

Well, here's the problem:

--- przed	2021-04-21 13:54:53.687958000 +0100
+++ po	2021-04-21 13:54:45.681533000 +0100
@@ -1,170 +1,169 @@
+gbde
 growfs
 rctl
-po
-dumpon
+geli
 dhclient
 Makefile
-natd
-ddb
-gbde
-sysctl
 ccd
-geli
-hostid
+natd
 swap
-zpool
+dumpon
+ddb
 fsck
 root
-zvol
-sppp
 serial
 mdconfig
+sppp
+sysctl
+hostid
+zpool
 hostid_save
+zvol
 mountcritlocal
 kldxref
-gssd
-tmp
 zfsbe
-devmatch
+tmp
+gssd
 sysvipc
-zfs
-kld
 linux
-localpkg
+kld
+devmatch
+zfs
 var
-cfumass
+localpkg
 cleanvar
+cfumass
 FILESYSTEMS
-ippool
-ldconfig
-addswap
-adjkerntz
 hostname
+ipsec
 ip6addrctl
+ippool
 netoptions
 opensm
 random
+adjkerntz
+addswap
 iovctl
-ipsec
-autounmountd
-geli2
-ugidfw
+ldconfig
 mixer
+ugidfw
+geli2
+autounmountd
 ipfilter
 ipnat
 ipmon
 ipfs
 netif
-ppp
-rtsold
-static_ndp
-static_arp
 pflog
-pfsync
 devd
 resolv
 stf
+ppp
+pfsync
+rtsold
+static_ndp
+static_arp
 defaultroute
-routing
-ipfw
 bridge
 zfsd
-route6d
+routing
+ipfw
 ipfw_netflow
-routed
+route6d
 pf
+routed
 blacklistd
 netwait
 local_unbound
 NETWORKING
+kdc
 tlsservd
+iscsid
 ctld
+pppoed
 kfd
-iscsid
-tlsclntd
 nfsuserd
-pppoed
-kdc
+tlsclntd
 ipropd_master
-kpasswdd
+nfscbd
+iscsictl
 ipropd_slave
 kadmind
-iscsictl
-nfscbd
+kpasswdd
 mountcritremote
-mdconfig2
-wpa_supplicant
-virecover
+hostapd
 accounting
-os-release
 cleartmp
+gptboot
 dmesg
-devfs
+wpa_supplicant
 motd
-gptboot
-hostapd
+virecover
+mdconfig2
+os-release
+devfs
 newsyslog
 syslogd
-bsnmpd
 ntpdate
-savecore
-watchdogd
-pwcheck
-hastd
 auditd
+hastd
 power_profile
+bsnmpd
+savecore
+pwcheck
+watchdogd
 auditdistd
-rpcbind
 SERVERS
+rpcbind
 nisdomain
 nfsclient
 ypserv
-ypxfrd
-ypupdated
 ypldap
+ypupdated
+ypxfrd
 ypbind
 ypset
 yppasswdd
-automountd
 keyserv
 quota
+automountd
 automount
 mountd
 nfsd
 statd
 lockd
 DAEMON
+local
+ntpd
+mountlate
+powerd
 rarpd
+lpd
 sdpd
 rtadvd
 rwho
-powerd
-ntpd
 nscd
-mountlate
-moused
-lpd
-local
 hcsecd
+moused
 bootparams
 apm
 ubthidhci
 utx
 ftp-proxy
 swaplate
-apmd
-bluetooth
 rfcomm_pppd_server
 bthidd
+bluetooth
+apmd
 LOGIN
-ftpd
-inetd
+syscons
 cron
 sshd
-jail
+ftpd
 othermta
 sendmail
 msgs
-syscons
-bgfsck
+inetd
+jail
 securelevel
+bgfsck

So either I'm missing something, or the sort order in rcorder(8) isn't particularly stable, which makes this comparison not very useful.

[imp]

So either I'm missing something, or the sort order in rcorder(8) isn't particularly stable, which makes this comparison not very useful.

rcorder is highly unstable. Merely adding a script w/o any constraints, can radically alter the output since it is a partial ordering...

[ngie]

In D29750#670653, @trasz wrote:

So either I'm missing something, or the sort order in rcorder(8) isn't particularly stable, which makes this comparison not very useful.

This is great information to include in the "Testing Done" section.

As @imp noted, the output from rcorder isn't stable, but that's kind of a "feature" in a way. It would be nice if there was gating requirements for the individual scripts to better constrain the search space, e.g., "disks" should come between checkpoints "a" and "b" in the boot up sequence.

What my concerns were mostly dealing with were major checkpoints, e.g., "NETWORKING", being out of order or providers being missing due to a rename or something. If sequencing gets out of order enough it could definitely cause grief if one's not careful due to implicit ordering :/.

The rcorder (the last time I really touched it a few years back) was very fragile, which is why I was very careful and intentional with the changes I made. Shifting around dependencies could affect implicit requirements of other rc scripts in the base system, and unfortunately also in ports :(.. I know it's gotten a bit more complicated with parallel rc script start, but I don't know how fault tolerant the FreeBSD rc(8) system is at restarting failed services/jobs these days, because I haven't looked into how the sausage is made.

There is different rcorder output (IIRC) which might be more useful for displaying the DAG, but I forget if it's on by default or you need to compile rcorder with a specific CFLAG to make it work.

I'll try to look through the actual rc scripts and provide useful feedback since it seems like we've run into a bit of a wall in terms of info gathering.

[trasz]

Sounds like you might also be interested in https://reviews.freebsd.org/D29753?

As for investigating dependencies, I've found rcorder -g to be really useful.