Solved order of things in /etc/rc.conf

After decades of using rc.conf by the seat of my pants, I'm just starting to try to really understand how the whole rc system is meant to work. From what I've read so far, it seems to me that the order of things listed in /etc/rc.conf is unimportant, but I'm just gathering that by implication; I have not seen anything specifically, explicitly stating so. Am I correct about this? Caveats:

(1) I know about rcorder. I'm not asking about that - in fact it's the main reason why I suspect that the order within /etc/rc.conf itself is unimportant.

(2) I understand rc.conf is a shell script, so obviously some things are important in order (e.g. perhaps one variable refers to another, or perhaps a function is defined and called). But I mean my question to apply to simple cases where the only things in rc.conf are lines setting variables to constant strings.

Thanks in advance.
 
rc.conf doesn't normally contain any executable commands. It only sets variables used by rc scripts. Order doesn't matter except if

a) You reference another within rc.conf,
b) execute commands (not recommended).

Then, like any procedural language, order matters. But if all you're doing is setting rc.conf variables you can order them in any order you wish.

Ideally you should use the service enable/disable command or sysrc command to manage your rc.conf for you.
 
Thanks cy@.

Could you please explain (or point me to an explanation) of why executing commands is "not recommended"? I'm asking because what I'm hoping to do (for the purpose of easing configuration management) is to have rc.conf call other scripts individualized for the thing in question, rather than everything in that one file.

For example, right now, I have source control and stow and so forth set up to have a distinct subunit for configuration of apache24, another for samba_server, and a third for rc.conf. But I view the rc.conf subunit as a kludge, as it has elements related to apache24, samba_server, et cetera. I would much rather have a sort of "master" rc.conf that just runs scripts from somewhere else, so that I could move (say) the apache24-related parts of my current rc.conf out of the rc.conf subunit and into the apache24 subunit. In that context, my question was intended to make sure that I knew whether or not I had to take order into account when calling the other scripts, or if I could do something simple like "call whatever scripts are in directory such-and-such" without worrying about ordering them.

Is there a reason why that sort of thing would be problematic? Or is the "not recommended" more along the lines of just "You'll shoot your eye out, kid"?

Thanks again.
 
Could you please explain (or point me to an explanation) of why executing commands is "not recommended"?
rc.conf is sourced each time /etc/rc.subr is sourced. This collection of functions is called by every rc.d(8) script. A command in rc.conf would get executed dozens of times during boot.

rather than everything in that one file.
Make use of /etc/rc.conf.d/
as it has elements related to apache24
Put the apache24 specific settings in /etc/rc.conf.d/apache24 or /usr/local/etc/rc.conf.d/apache24.
 
Thanks SirDice. That doesn't seem particularly awful to me, in my context. It would just be (for example) dozens of "invoke samba-rc, which in turn sets the value of samba_server_enable", rather than dozens of "set the value of samba_server_enable", right? I can't imagine I'd ever even notice a performance hit from that.
 
That last reply of mine was to before you edited your comment to include stuff about /etc/rc.conf.d. Now that I see that part, rc.conf.d looks like exactly what I'm hoping for. Thanks again!
 
Back
Top