Quick fun question: only set an rc.d variable sometimes?

From: Dan Mahoney (Gushi) <freebsd_at_gushi.org>
Date: Tue, 28 Sep 2021 03:23:43 UTC
Hey all,

I'm dealing with rc.d scripting and reading 

Here's my question: Is there a sane way to have something like foo_pid 
*completely unset* in one case, but overridable by rc.conf after?

It took me a bit to wrap my head around the:

: ${dummy_enable:=no}
: ${dummy_msg="Nothing started."}

Examples.  (Why that first colon, what is this := syntax), etc.

What I'm trying to say in rc.subr language is:

If the user has set something in rc.conf, use it.  Otherwise, leave it 
TOTALLY UNSET.  Not to the null string.  Undefined.

Anyway, here's my use case:

The "kdc" program can optionally have a pidfile (if you install mit krb5, 
it uses the same startup script rather than one in /usr/local/etc/rc.d)

But the base kdc doesn't support a pidfile at all.  So "status" won't work 
if pid is set at all in /etc/rc.d/kdc -- but if it's unset, rc_subr will 
just search for the process without the pid, by name.

A line like the one above would define it.  Even to a default.  So it 
would break "status".  But I'd like to actually be able to *check* a 
pidfile if I configure one.  Since then a cleaner shutdown is possible, 
and code that relies on this stuff externally, like puppet, are cleaner.

This isn't about "why is a port using a base startup script, especially 
when that port drops other files into /usr/local/etc/rc.d", it's more a 
"hey, this syntax isn't clear in the above article, and how does one do 
it, and should it be added to the above?"


--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
FB:  fb.com/DanielMahoneyIV
LI:   linkedin.com/in/gushi
Site:  http://www.gushi.org