Hey all,
I'm dealing with rc.d scripting and reading
https://docs.freebsd.org/en/articles/rc-scripting/
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
---
