Does order of things in rc.conf matters ?

Not as far as I can see, as long as definitions in there don't reference each other. The whole file is sourced, so it only matters what variables are set at the end.

By "don't reference each other", I mean the following:
Code: 
a=1
b=$a
a=2
If you execute this as written, b will be 1. If you reverse the order of these three lines, then b will be 2.[/code]
 
Some matters but some doesn't.
For modifying / adding to same variable, for example, kld_list, it matters.
But /etc/rc.conf contains configurations for multiple rc scripts in single file.
Anything handled by different script are, random. Precisely, depends on how rcorder(8) decides the order of scripts to run.
 
Forgot to mention.
/etc/rc.conf itself is actually a sh(1) script.
So something like below in it works.

sh: 
if [ "vt" = `sysctl -n -q kern.vty` ]
then
  keymap="jp.kbd"
  if [ -r /usr/share/vt/fonts/b16.fnt ] ; then
    allscreens_flags="-f /usr/share/vt/fonts/b16.fnt"
  fi
else
  keymap="jp.106.kbd"
fi
 
GlitchyDot said:
Can you explain this with an example ?
Click to expand...
For example, if you describe (old expression)
sh: 
kld_list= a
kld_list= ${kld_list} b
kld_list= ${kld_list} c
kld_list= ${kld_list} d
kld_list= ${kld_list} e
and there are no relationship within a.ko, b.ko, c.ko, d.ko and e.ko, these should be loaded in this order.
This is equivalent with
sh: 
kld_list= a b c d e

Note that if b.ko depends on e.ko and autoloads it on its initialization phase,
modules would be loaded in the order a.ko, b.ko, e.ko, c.ko and d.ko.

Here, if c.ko hesitates to work properly if e.ko is loaded but b.ko and e.ko are fine even if c.ko is loaded first, you should describe the above like
sh: 
kld_list= a
kld_list= ${kld_list} c
kld_list= ${kld_list} b
kld_list= ${kld_list} d
kld_list= ${kld_list} e
or even
sh: 
kld_list= a
kld_list= ${kld_list} c
kld_list= ${kld_list} b
kld_list= ${kld_list} d
as e.ko is promised to be loaded by b.ko. Order of b.ko and d.ko wouldn't matter if both works properly in this order.
 
UPD: oh, folks, I'm sorry, I misunderstood the question. I though it was: 'does order of things in rc matter?'. I'm terribly sorry, I answered _that_ question, not the real one. Well, at least, I hope, someone may find my post helpful one day, I won't delete it.

Yes, it does matter. I've figured this out for myself just a couple of days ago, when I was trying to make one of my custom shell scripts run on system startup via rc(8).

I want to make it clear with simple example: in FreeBSD (I guess that virtually everybody has this enabled) your /tmp directory is cleaned up on every system boot. How does it happen? For this, there is a dedicated rc(8) task, that is called 'cleartmp', it is located in /etc/rc.d/cleartmp and can be enabled by including line clear_tmp_enable="YES" in your /etc/rc.conf (see rc.conf(5)). Every time your machine boots, rc(8) executes this task and /tmp gets clear.

Now, imagine that this task does not exist and we want to write it ourselves. System boot consists of lots of pieces, and they are executed in a strict order. One of this pieces is mouting filesystems. But, root filesystem (/) must be mounted first, because it provides essential stuff, like things in /bin, /sbin and /etc. And then, after first essential boot tasks are done, other filesystems are mounted. Very often we have /usr, /home, /var, /tmp (different combinations are possible) on different partitions, thus, during the boot there's a certain period of time, when these filesystems are _not_ available. And since rc(8) can execute tasks on system boots (order of stages of which does matter) it becomes clear that order of rc(8) tasks does matter too. Indeed: we want to execute task on boot, but when exactly do we want it to be executed: when root filesystem is mounted, when all filesystem are mounted, when a particular kernel module is loaded? There is in fact a whole host of these questions, I'm just not getting into the weeds. Getting back to our task: we clearly want to execute our task (that clears /tmp) when /tmp itself is available, thus, after /tmp filesystem is mounted.

To accomplish this, we should add a certain type of 'comment' in our script, that will be read by rcorder(8): # REQUIRE: tmp. 'tmp' here is name of the rc(8) task that mounts /tmp (see /etc/rc.d/tmp).

Another example: if our script employs some utility under /usr/local/bin, then we should add # REQUIRE: FILESYSTEMS, to ensure that root and other critical filesystems are mounted.

Or if our script has to be run before another rc(8) task (say, sshd(8)), then we would add: # BEFORE: sshd.

You can read more about these comments in rc(8) and rcoder(8).

Basically, if your rc(8) script does not include any of these-like 'comments', then rcorder(8) will think: 'hey, this thing does not require anything, so I would put it it the begining of the task queue (i.e. execute it as early as possible)'. Indeed, if you would try to make a simple script and won't provide any conditions for it, then run rcorder /etc/rc.d/* /usr/local/etc/rc.d/*, you will see, that your script is almost one of the first things scheduled. I suspect, in 99% of the cases, this is not want you actually want (and it almost certanly would not work).

So, short summary: does the order matter? Yes, it kind of does :-)
 
T-Aoki said:
/etc/rc.conf itself is actually a sh(1) script.
Click to expand...

T-Aoki said:
For example, if you describe (old expression)
sh: 
kld_list= a 
kld_list= ${kld_list} b
Click to expand...

While I have no doubt about the general idea and intention of these examples, as this is run as a sh(1) script, there is one particular sh(1) pitfall, Sh - the POSIX Shell - Variables:
Do not put a space after the equals sign. This terminates the value.
Click to expand...
T-Aoki said:
sh: 
kld_list= a 
kld_list= ${kld_list} b
Click to expand...
should be:
sh: 
kld_list=a 
kld_list="${kld_list} b"

For example:
Code: 
[1-0] # grep '^b' </etc/rc.conf
b1=a b
b2= zz
b3=QQ YY
b4= "AA BB"
[2-0] # sysrc -f /etc/rc.conf b1 b2 b3 b4
sysrc: unknown variable 'b1'
sysrc: unknown variable 'b2'
sysrc: unknown variable 'b3'
sysrc: unknown variable 'b4'
[3->1<] #
 
A
Erichans said:
While I have no doubt about the general idea and intention of these examples, as this is run as a sh(1), there is one particular sh(1) pitfall, Sh - the POSIX Shell - Variables:


should be:
sh: 
kld_list=a
kld_list="${kld_list} b"

For example:
Code: 
[1-0] # grep '^b' </etc/rc.conf
b1=a b
b2= zz
b3=QQ YY
b4= "AA BB"
[2-0] # sysrc -f /etc/rc.conf b1 b2 b3 b4
sysrc: unknown variable 'b1'
sysrc: unknown variable 'b2'
sysrc: unknown variable 'b3'
sysrc: unknown variable 'b4'
[3->1<] #
Click to expand...
Ah, thanks! Maybe I've mangled the syntax with Makefile on writing example.
 
tembun said:
UPD: oh, folks, I'm sorry, I misunderstood the question. I though it was: 'does order of things in rc matter?'. I'm terribly sorry, I answered _that_ question, not the real one. Well, at least, I hope, someone may find my post helpful one day, I won't delete it.

Yes, it does matter. I've figured this out for myself just a couple of days ago, when I was trying to make one of my custom shell scripts run on system startup via rc(8).

I want to make it clear with simple example: in FreeBSD (I guess that virtually everybody has this enabled) your /tmp directory is cleaned up on every system boot. How does it happen? For this, there is a dedicated rc(8) task, that is called 'cleartmp', it is located in /etc/rc.d/cleartmp and can be enabled by including line clear_tmp_enable="YES" in your /etc/rc.conf (see rc.conf(5)). Every time your machine boots, rc(8) executes this task and /tmp gets clear.

Now, imagine that this task does not exist and we want to write it ourselves. System boot consists of lots of pieces, and they are executed in a strict order. One of this pieces is mouting filesystems. But, root filesystem (/) must be mounted first, because it provides essential stuff, like things in /bin, /sbin and /etc. And then, after first essential boot tasks are done, other filesystems are mounted. Very often we have /usr, /home, /var, /tmp (different combinations are possible) on different partitions, thus, during the boot there's a certain period of time, when these filesystems are _not_ available. And since rc(8) can execute tasks on system boots (order of stages of which does matter) it becomes clear that order of rc(8) tasks does matter too. Indeed: we want to execute task on boot, but when exactly do we want it to be executed: when root filesystem is mounted, when all filesystem are mounted, when a particular kernel module is loaded? There is in fact a whole host of these questions, I'm just not getting into the weeds. Getting back to our task: we clearly want to execute our task (that clears /tmp) when /tmp itself is available, thus, after /tmp filesystem is mounted.

To accomplish this, we should add a certain type of 'comment' in our script, that will be read by rcorder(8): # REQUIRE: tmp. 'tmp' here is name of the rc(8) task that mounts /tmp (see /etc/rc.d/tmp).

Another example: if our script employs some utility under /usr/local/bin, then we should add # REQUIRE: FILESYSTEMS, to ensure that root and other critical filesystems are mounted.

Or if our script has to be run before another rc(8) task (say, sshd(8)), then we would add: # BEFORE: sshd.

You can read more about these comments in rc(8) and rcoder(8).

Basically, if your rc(8) script does not include any of these-like 'comments', then rcorder(8) will think: 'hey, this thing does not require anything, so I would put it it the begining of the task queue (i.e. execute it as early as possible)'. Indeed, if you would try to make a simple script and won't provide any conditions for it, then run rcorder /etc/rc.d/* /usr/local/etc/rc.d/*, you will see, that your script is almost one of the first things scheduled. I suspect, in 99% of the cases, this is not want you actually want (and it almost certanly would not work).

So, short summary: does the order matter? Yes, it kind of does :-)
Click to expand...
Awesome!
Now this is a deeper hole i like to explore now. :)
 
GlitchyDot said:
Awesome!
Now this is a deeper hole i like to explore now. :)
Click to expand...
Well, order can matter, but I'm not sure how to manually set the order of loading. Please see my post https://forums.freebsd.org/threads/virtualbox-host-freebsd-plasma-guest-black-screen.98362 where I had graphical screen problems in VBox, realized that it works if .ko and service are disabled in rc.conf and loaded manually after login, so I moved them to the rc.local which should be called only after all is done from rc.conf, and all works. Go figure?
 
Last edited:
You must log in or register to reply here.
Back
Top