reread rc.conf without rebooting

[Polytropon]

On Sun, 3 Sep 2017 13:13:52 +0100, Frank Leonhardt wrote:
> On 29/08/2017 15:35, Ernie Luzar wrote:
> > Valeri Galtsev wrote:
> >> On Tue, August 29, 2017 9:07 am, Ernie Luzar wrote:
> >>> After making changes to /etc/rc.conf is there some way to make the host
> >>> reread it without rebooting?
> >>
> >> I only know one way to do it: apply each change (one at a time) by
> >> executing relevant command from shell. Why does that not suite you? 
> >> You do
> >> test (from shell) what is the effect of each change, right?
> >>
> >> Valeri
> >>
> >
> > You did not understand correctly meaning of post.
> >
> > I added local_unbound_enable="YES" to rc.conf
> >
> > It's my understanding that rc.conf is only read at boot time to config 
> > services on host.
> >
> > Question is. Is there some other way to make tis happen without 
> > rebooting?
> 
> Hi Valeri,
> 
> I understand what you mean. I have wanted to be able to do this for a 
> very long time but I have never found a way. init (process 1) runs all 
> the rc scripts, and AFIK is responsible for parsing them. Restarting 
> /sbin/init is almost as drastic and rebooting, and probable less likely 
> to work!
> 
> The problem is that when you experiment starting and stopping services 
> with /etc/rc.d/xxxx or the new service command it is difficult to be 
> sure you have put the working commands in /etc/rc.conf. The syntax is 
> different and it is also easy to make a mistake when typing.
> 
> You CAN put startup configuration lines in /etc/rc.local and run this 
> any time you like, but it is run at a different time during startup so 
> it is not a perfect solution. However, you do know that exactly the same 
> thing will happen at startup.

Be careful with this assumption. At startup, /etc/rc.local is run
at a time where it might be inconvenient for the problem you want
to solve. For example, if you want to do something with printers,
you'll be surprised that CUPS isn't running yet. But you can do
things with devices to mount.

See "man rc" for the explanation of rc.local and rc.shutdown.local.

Do not imagine rc.conf as a "one-time start script" - it isn't.
The key advantage (and maybe disadvantage?) is that it is being
parsed several times, especially by the services started via the
rc.d framework (from the /etc/rc.d and /usr/local/etc/rc.d directories
primarily). This framework resolves service dependencies as needed,
and all changes that apply to _affected_ services will be used.
In rc.conf, a declarative syntax is being used (name=value), and
its content is being sourced by any script that needs to obtain
configuration values from that file. There is not a single-point
mechanism that extracts values from it and distributes them among
services that might need them, so to speak. :-)

The rc.local file _can_ use values from rc.conf (or rc.conf.local),
but it is not directly related to that file, as it is a regular
shell script that is executed "for the sake of execution", whereas
rc.conf, being a shell script too, is "only a name=value list".#!/bin/sh

Here is an example of how rc.local can start:

# obtain configuration with "precedence" (from 
if [ -z "${source_rc_confs_defined}" ]; then
	if [ -r /etc/defaults/rc.conf ]; then
		. /etc/defaults/rc.conf
		source_rc_confs
	elif [ -r /etc/rc.conf ]; then
		. /etc/rc.conf
	elif [ -r /etc/rc.conf.local ]; then
		. /etc/rc.conf.local
	fi
fi


# depends on no further configuration
echo -n " foo"
/usr/local/bin/foo -meow



# depends on _enable="YES" and others in rc.conf(.local)
case ${bar_enable} in
[Yy][Ee][Ss])
	if [ -f ${bar_file} ]; then
		echo -n " bar"
		/opt/bin/bar ${bar_flags} ${bar_file} &
	fi
	;;
*)
	;;
esac


# another one
echo -n " baz"
/usr/bin/true > /dev/null

# file ends here, trailing "." will be printed by caller


Note that /etc/rc.shutdown.local can use the same concept.



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...